


f 


ns Cain 






Institutional Archive of the Naval Postgraduate School 


Calhoun: The NPS Institutional Archive 
DSpace Repository 


Theses and Dissertations 1. Thesis and Dissertation Collection, all items 


1975 


High-level language compiling for 
user-definable architectures. 


Simoneaux, Donald Carlton 


Monterey, California. Naval Postgraduate School 


http://ndl.handle.net/10945/20887 


Downloaded from NPS Archive: Calhoun 


| Calhoun is the Naval Postgraduate School's public access digital repository for 
F (8 D U DLEY research materials and institutional publications created by the NPS community. 
«ist | | Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS'‘s first 


m \ KNOX appointed — and published -- scholarly author. 
aes | | : Dudley Knox Libra Naval Postgraduate Schoo 

LIBRARY dley b ry | | g d hool 
http://www.nps.edu/library 






411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 

















25 
sre 


ALE. Esc 
~ conte HOOL 
NTEREY, CALIFORNIA 93949 


Beat 


NAVAL POSTGRADUATE SCHOOL 


honterey, Galifornta 





THE 


High-Level Language Compiling 
For User-Definable Architectures 





by 


Donald Carlton Simoneaux 


i Thesis Advisor: V. M. Powers 


Approved for public release; distribution unlimited. 


716978] 


June 1975 





SECURITY CLASSIFICATION OF THIS PAGE (When Data Entered) 


READ INSTRUCTIONS 


REPORT DOCUMENTATION PAGE BEFORE COMPLETING FORM 


1. REPORT NUMBER 2. GOVT ACCESSION NO} 3. RECIPIENT'S CATALOG NUMBER 









4. TITLE (and Subtitie) S. TYPE OF REPORT & PERIOD COVERED 


High-Level Language Compiling For User- Electrical Engineer 


Definable Architectures June 1975 
6. PERFORMING ORG. REPORT NUMBER 


7. AUTHOR(e) 8. CONTRACT OR GRANT NUMBER(e) 


LT Donald Carlton Simoneaux 


9. PERFORMING ORGANIZATION NAME AND AOORESS 10. PROGRAM ELEMENT, PROJECT, TASK 
AREA & WORK UNIT NUMBERS 


112. REPORT DATE 
June 1975 
er. CP ee 


1S. SECURITY CLASS. (of thie report) 


Naval Postgraduate School 
Monterey, California 93940 





11. CONTROLLING OF FICE NAME AND ADDRESS 








Naval Postgraduate School 
Monterey, California 93940 


a. MONITORING AGENCY NAME & ADDRESS(If dilferent from Controlling Office) 




















Unclassified 


1Sa. DECLASSIFICATION/ DOWNGRADING 
SCHEOULE 


Naval Postgraduate School 
Monterey, California 93940 






16. DISTRIBUTION STATEMENT (of thie Report) 


Approved for public release; distribution unlimited 


17. DISTRIBUTION STATEMENT (of the ebetract entered in Block 20, {f different from Report) 


16. SUPPLEMENTARY NOTES 


18. KEY WORDS (Continue on revoree side if neceesery and identity by block number) 
High-level language, compiler, hardware design language, Microcomputer 
programming, PL/M, configuration-independent compiler, software engineering, 
code optimization, modularity 


20. ABSTRACT (Continue on reveree efde if neceesary and {dentity by block number) 

The development of large-scale integrated circuits in the last few years 
has resulted in a rapid increase in the number of digital devices available 
for electronic system design. Skilled system designers often do not have an 
abundance of software experience and require better tools than are presently 
available in order to take maximum advantage of microprocessors and other 
functional building blocks. A case is made for the development of a high- 
level language compiler which will allow the designer to specify not only 
his algorithm but also his hardware confieuration and his optinizarion 


DD , Sebet 1473 = EDITION OF 1 NOV 65 IS OBSOLETE 


Page S/N 0102-014 6601 | 
( ; 5 1 SECURITY CLASSIFICATION OF THIS PAGE (When Data Entered) 








SECURITY CLASSIFICATION OF THIS PAGE(MYhen Deta Entered: 


Block #20. 


constraints. The PL/M compiler developed by Intel Corporation is used as 
a model for examining some of the requirements of this 'machine- 
independent'"’ compiler. A summary of work which was done to implement the 
first stages of such a compiler is presented, and factors which must be 
considered in order to further this work are discussed. 


DD Form aly 
Pan fe 
S/N 0102-014-6601 


SECURITY CLASSIFICATION OF TRIS PAGE(When Dota Entered) 





Hiah-Level Lanauagae Compilina 
For User-Definable Architectures 


by 


Donald Carlton Simoneaux 
Lieutenant, United States Navy 
bse Lu lane piversi ty, soc? 
M.S.E.E.<~, Naval Postaraduate School, 1974 


Submitted in:-oartial fulfillment of the 
requirements for the degree of 


PREC terenL. ENCTNEER 


from the 


NAVAL POSTGRADUATE SCHOOL 
June 1975 





ABSTRACT 


The development of large-scale integrated circuits in 
the last few years has resulted in a rapid increase in the 
number of digital devices available for electronic system 
desian. Skilled system designers often do not have an abun- 
dance of software experience and require better tools than 
are presently availaole in order to take maximum advantage 
of microprocessors and other functional building blocks. A 
case 1S made for the development of a high=level language 
compiler which will allow the designer to specify not only 
his algorithm but also his hardware configuration and his 
optimization constraints. The PL/M compiler developed by 
Intel Corporation is used as a model for examining some. of 
the requirements of this "machine~independent” compiler. A 
Summary Of work which was done to implement the first Stages 
of such a compiler is Dpaen tea: and factors which must be 


Somsidered in order to further this work are discussed. 
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I. INTRODUCTION 


fe PRUBLE“’ DEFINITION 

The most promising and widely discussed device in the 
electronics industry during the last few years has been the 
microorocessor. Tnis device packages the central processing 
unit and associated elements of a digital computer into a 
handful of integrated circuit chipss in many cases only one 
care 1S used. Since the advent of the microprocessor in 
1971 it has become much easier to incorporate the power of a 
digital computer into the design of an electronic system. 
Compared with custom Larae Scale Integration (LSI) circuits 
microprocessors are convenient, flexible, low-cost devices 
which have allowed sophisticated features to be made avails 
able in relatively simple systems. As a result their use 
has expanded rapidlyr and many people who have had _ limited 
programming experience are now being forced to write oro- 
Qrams as part of their design efforts. 

The term "firmware" has come to be used for systems 
which utilize programmable digital components, since the 
development of such systems requires both hardware and 
software desiqn. Tne design of a firmware systemr, whether 
it useS a microprocessor or some other means of providing a 
programming caoaoilitys iS a complex task requiring the best 
skills of voth tne electronics engineer and the computer 


programmer. 





Anotner development which, although conceived in the 
early 1950'sS- has become significant only in the last decade 
is the use of microproagramming in digital systems. Mie 
croproaramming differs from “normal" programming primarily 
in the level of detail considered. Each instruction in the 
instruction set of a typical digital computer requires 
Several hardware operations to be performed, but these 
operations are transparent to the programmer. In microoro> 
grammable systems each of these primitive operations may be 
invoked by a microinstruction. Initially, as in the I6M 
System/360r microprogramming was done only by the manufac- 
turer, but today there are general purpose computers (le.g., 
the Hewlett=Packard HP-2100 and Burroughs "D" machine) which 
allow user microprogramming. In addition there are propo- 
Sals for using standard functional modules in the implemen- 
tation of special purpose digital systems (56). These modu- 
lar systems will be controlled by what amount to micropro- 
grams. 

As in the case of the micronorocessors microprogrammed 
Systems will in most instances be programmed by engineers 
who have ae firm background in hardware agesiaqn but who may 
have minimal software experience. Thus it 1S becoming jin-= 
creasingly necessary that programming languages be developed 
which are easy to use and which can produce good control 
code for a variety of architectures. The compiler for such 
@ language could be considered a software comouter aided 


desiaqn (CAD) tool for the enaineer. Ideallyr it would 
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Becept™sa description of the sligorithm to be performed (the 
program) and descriotions of the hardware and the format of 
the control codes the output would then be a control program 
to perform the alaorithm. 

Succeeding chavters of this thesis examine some of the 
considerations necessary in the development of a programming 
language for firmware system design. Chapter I[II-contains a 
discussion of orogramming languages and the advantages and 
disadvantages of high-level languages. The language PL/™ is 
presented in Chapter III and is used as a basis for examin= 
ing the necessary fenennne of a high-level language. The 
implementation of pass 1 of a PL/M compiler is described in 
Miraoter I[V. This chapter also describes some of the 
theoretical aspects of programming language design and im- 
plementation. The output of pass 1 iS an intermediate 
language representation of a source Sanguaqe programs an 
important concept which is discussed in Chapter V. 

A major factor in the implementation of any digital sys- 
tem is the system architecture. Chapter VI contains 
descriptions of various types of architectures and a discus= 
sion of the influence of architecture on language design. 
Betymization of the output code is another important con- 
sideration in the design of a compiler. Many firmware sys 
tems will be produced in large numbers, and the amount of 
hardware used will have a significant impact on the cost. 
Because of the fierce competition among manufacturers, aqood 


optimyzation techniques will be critical in the 


1} 





imolementation of these systems. Chapter VII 1s devoted to 
the toovic of compiler optimization. 

The .topics discussed in Chapters IV-VII are tied togeth- 
er in Chaoter VIII+, which Shows how they all influence’ the 
desiaqn of a compiler for user-definable architectures. 
Chapter IX Summarizes the conclusions reached during the 
Study of the problem and presents a list of recommendations 


for future work. 


Be. SOFTWARE ENGINEERING 

With the rapidly growing use of digital techniques in 
electronic system design has come the emergence of a new 
discipliner that of software engineerinags to address prob- 
lems at the hardwaressoftware interface. Although digital 
Computers have been in existence for more than 30 years, it 
is only today becoming widely recognized that the software 
design considerations are at least as important as the 
hardware design considerations in digital system development 
[11}. Tne acceptance of the fact that software problems are 
of more than acadenic interest is highlighted by the recent> 
ly inaugurated publication of a new technical Journale--the 
IEEE Transactions on Software Engineering. Because software 
engineering addresses many issues which are very closely 
related to the firmware design provdlem, its goals and 
principles-*as defined by Ross;, Goodenough, and Irvine 
(Sile-are outlined below. These ideas have a strong influ- 


ence on much of the remainder of this thesis. 


ie 





The goals of software engineering ares 


1) Modifiability=~This refers to the ability to make con- 


Ey) 


sy) 


4) 


trolled changes 1n & program. In a large system 
software modifications nave to be made during develop= 
ment aS well as after oroduction has bequn. Modificea= 
tions may be made either to correct errors or to change 
or add features and provide varying levels of perfor=- 
mance (1.e.r 32 “family" of systems). 

Efficiency="This goal is concerned with the best utili 
zation of the resources) available. Tyeically <hias 
means using the least memory and time in performing the 
task. Efficiency is usually "... prematurely permitted 
a high priority in engineering tradeoffs ... {but]) does 
not dominate the practice of software engineering." 
Poly eo. €0=ci) 

Reliabilityr-This is a critical aoalr especially for 
software systems used in realtime control applica~ 
tions. Unfortunately reliability has too often in the 
past been considered as secondary to efficiency in 
software development. 

Understandability*-This goal supports the goals. of 
modifiability and reliability. If a piece of software 
1s easily understandable, it is easy to modify and easy 
to check for reliability. It is unfortunate that un- 
derstandability is usually considered to reduce effi-~ 
ciency, but this relationship does not necessarily 
hold. Increased understandability can lead to the 
detection of inefficiencies in a large system. 
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There are seven principles of software engineering which 
may be applied in order to achieve the goals. These princi 
ples are: 

1) Modularity-r*This refers to the purposeful structurina 
of a system. Modularity 1S an important porinciple in 
both hardware and software design. 

2) Abstraction-"-The unessential details are omitted at any 
Qiven level in the desian, leaving only abstract con- 
cepts for consideration. 

5) Localization--Limiting the scope of a structure or a 
concept is closely related to modularity. Localization 
enhances confirmability and understandability. 

4) Hidingew"...6 [Tl]he purpose of hiding 1s to make inacm 
cesible certain details that should not affect other 
parts of a system." ([5l, p.ec2) 

5) Uniformity-*lt is important that definitions and cone 
cepts be applied uniformly across a system. 

6) Completenesse=*Specifying all details and leaving Reene 
ing to Chance aqreatly increases reliability. 

7) Confirmabilitye-*This refers to the ability to determine 
whether all the desiqn goals have been met. 

Software engineering 1S concerned with the question of 
whether it 1S more important to have very efficient coder in 
me sense that it uses the minimum amount of memory and exer 
cutes at the maximum rate (two qoals whichs oy the way, are 
usually not conpatible), or whether it iS more important to 


have code which is reliable, easy to modify, and takes a 
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minimum amount of time to develop. As in all engineering 
disciplines, software engineering is involved with making 
tradeoffs among the various alternatives, since no. one 


answer will be correct in all situations. 
? 


i> 





If. PROGRAMMING LANGUAGES 


In the early days of digital computer use it became evice- 
dent that an alternative to machine Jlanquage programming was 
needed. A computer program is really nothing more than a 
series of binary digits contained in some storage medium, 
but human engineering dictated that early machine lanauagce 
proarams be represented as groups of octal digits. With the 
introduction of mnemonics and assemblers to translate them, 
programs vecame almost readable. Assemblers became more and 
more sophisticated with the addition of macroSs comment 
fieldse and conditional assembly featureSr but programs 
Still were tedious to write and difficult to read. The 
drawback of assenbly language programs 1s that they contain 
too much information abpout the operation of the hardware 
Meqntrary to the principle of abstraction), and this tends 
to obscure information ieee to the algorithm being imole- 
mented. Since there is essentially a one-to-one correspon= 
dence between assembly language instructions and machine 
Instructions, assempoly language programs still tend to be 
very cumbersome and error-prone except when used for very 
Simole problems. Thusr as programs became increasinaly com= 


Plex,s high-level languages were introduced. 


ae THE CASE FOR HIGH"-LEVEL LANGUAGES 
the development of high-level languages was Spurred by 
the desire to be able to write programs which are more 
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@escriptive of the problems being seeceaad which depend 
less on the actual hardware on which the programs are _ to 
execute.. "Highstorder tanguagesS represent a concept for 
improvina the understandability of programs by abstracting 
from the details of computer instruction sets.” (Sir 9.19) 
These languages are designed to facilitate description of 
the procedural steps involved in problem solutions and thus 
they are often referred to aS procedureroriented lanauages 

(as opposed to machineroriented assemoly languages). 
The main advantages of programming in a high-level 

language ares 
1) the programmer is freed from the considieration of many 
minor details. These details are mainly in the nature 
of bookkeeping=ememory allocations register allocations 
assignment of temporary variables to hold the results 
of partial conputations, remembering branch locations, 
type checking of variablesr and many others. This face 
tor iS becoming even more important with the increased 
use of microprogrammable systems. "The inability of a 
user to cope with a highly intricater timetand=machine 
dependqent environment often results tin inefficient, if 
not error prone, Be OAE ams." (47, p.791) 
2) Efficient control structures greatly reduce the burden 
of programming, resulting in increased reliability. 

5) Symbolic user variables increase the readability of the 
program. This is also one of the advantages assembly 


languages have over machine languages. 
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4) The ability to write arbitrary Me ehmecic expressions 
also increases readability and tends to reduce computa 
tional errors. 

5) Programmer productivity iS increased because of the 
expansion factor involved in the translation from 
high-level language to machine language. It is gen- 
erally recognized that proarammers producers on averaae 
in a large projects, only a few lines of code per day, 
whether it be machine coder, assembly coder, or highe- 
level language code. 

6) Documentation is improved, because the program 1S more 
understandable, A good hiagh=level language encourages 
the writing of programs which are essentially self- 
eee . 

7) Maintenance, modification, and debugging are facilitat- 
eUmeoeccouse sot eChen imp noved readabilyty and document ta= 
tion. 

8) Transportability is improved, because ae highlevel 
lanquage has little dependence on a particular machine 
architecture, In fact one goal of language design 1s 
complete machine indeoendence. This topic iS covered 
more fully in Chaoter VIII. 

By far the most popular criticism o f high-level 
languages 1S based upon the concern for efficiency. There 
are basically two sources of inefficiency. The first has to 
do with the fact that in certain instances Some lanauages 
are too machine independent in that they do not recognize 
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features which are basic to computer hardware. For example, 
FORTKAN does not contain primitive operations for bit manip= 
ulation (shiftings rotating, maskings etce). A good high- 
level language should not restrict the programmer from doing 
anything that he could do at the assembly or machine 
language levels. 

The second source of inefficiency lies within the code 
generation orocess and 1S really a characteristic of the 
compiler rather tnan the language. The complaints most 
often voiced by those opposed to the use of a high-level 
lanauage are that the compiler generates too much code and 
that the code generated 18 wasteful of time. However, the 
point 1S uSually demonstrated with only a small program 
mo, 435). 

These inefficiencies are really local in nature, since 
each instance can usually be isolated to ae few lines” of 
code. 4A gooa assembly language programmer can write locally 
"optimal" coder nut in a large program his cooe will suffer 
from global inefficiencies (see advantage (1) above). Thus 
"ee data based upon comparisons between small proaqrams wil) 
tend to underestimate the advantage of the higher level 
language for large programs." (23, p.e2l4) Many large pro- 
grams written tn high=level languages would have been very 
difficult and costly to write in assembly language (34) and 
orobabdly would have been less efficient. 

It 1S doubtful whether any compiler will ever be able to 


generate conpletely locally optimal code (as compared with 
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assembly language versions), but there are many promising 
tecnniques emerging (see Chapter VII). Experience has shown 
that gloval inefficiency iS a nonlinear function of program 
length, and a good compiler can usually produce more effi- 
cient code than an assembly lanquage programmer for orograms 
longer than about 50 to 100 high-level language statements 
[25]. For shorter programs an enqineering decision must be 
made as to whether the advantages of programming in a highs 
level language outweigh the loss in efficiency. A more com- 
mlete discussion of this topic is presented in Section 
VIT.A. AS memory costs continue to fall, the extra code 
qenerated by the local inefficiencies 1N a compiler will 
take on lesser significance even in small system aesign pro- 


jects. 


Bre SYSTEM PROGRAMMING LANGUAGES 

An area very closely related to firmware design is that 
of system programming. For many years system programmers 
have avoided the use of eer languages, and for the 
Same reason that the designers of programmable hardware 
(firmware) are now avoiding them--ineffiency. In addition 
to the fact that software engineering considerations” are 
Causing this position to be reevaluateds many advances have 
been made in the past few years in the area of programming 
language design. The development of qoodr, machine= 
independent, high-level languages for system programming has 
been studied for several wee (21,40), and a few lanquages 


have been imolemented, 
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The UNIX operating system [50], Leta for the popular 
PDP-11 series of minicompouterss, is currently in use at more 
than 50 .installations around the country (Cincluding the Com- 
puter Science Laboratory at the Naval Postgraduate School) 
ang was written almost entirely in the C language [49]s an 
Algol=like high=level language. In fact, the C compiler 
itself was written in C. The fact that an interactive, 
multisuser overating system as sophisticated as UNIX can be 
implemented satisfactorily on a minicomputer confirms the 
viability of high-level language programming in a situation 


requiring efficient machine code. 


C. COMPOSITE LANGUAGES 

One alternative solution to the problem of choosing 
netween a high=level language and an assembly language is 
the composite language**a language which has (hopefully) the 
best features of both. The simplest implementation is a 
high=level language which allows assembly code to be insert- 
ed into a program. PL/560 1S an example of this type of 
lanquage. The advantage of using such a language is claimed 
to lie 1M in the ability to make use of the efficiency of 
the assembly language while retaining the benefits of high- 
level language programming. 

Aside from the loss of understandability there are two 
major disadvantages in using thisS approach. First is the 
loss of machine independence, which reduces transportabili- 
ty. Each time the architecture of the hardware is changed 


(e.g.r by using a different processor or by rearranging a 
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modular system), the program must be carefully examined for 
instructions which need to be changed. The second disadvan~ 
tage 1S the reduction in reliability brought about by the 
fact that the programmer is allowed access to facilities 
which normally are comoletely controlled by the compiler. 
This can lead to conflicts (e.ger in resource allocation) 
and may cause unexpectea results and subtle side effects 
which are difficult to trace. 

These disadvantages were partially overcome 1n the ime 
plementation of the Language for Systems Development (LSD) 
PaO} . In LSD the use of assembly language 1S restricted to 
macros whose definitions are separate from the program it- 
self. Except for the fact that the Rta Garcnn TAOS seems 
somewhat clumSyr this aporoach orobadly comes very close to 
the ideal notion of a machine=independent compiler. 

A slightly different approach was taken by Popper [43] 
in the implementation of S4AL, which iS in essence an assem~ 
bly language with some of the structure of a high-level 
lanquaqge. A SMAL orogram equivalent to the examole present 
ed in Section VII.A was written by Popper, and it required 
only four more bytes of memory than the assembly lanquaqe 
version. Although the SMAL version is easier to read than 
the assembly language version, it 18 more difficult to read 
than the PL/M version. 

Composite approaches such as Popper's probably will be 
very beneficial for programmers who are designing smal] 


microprocessor systems but they do not appear to provide the 





best longrrange solution to the firmware design problem, 
Succeeding sections will make it evident that compiler 
theory 1S advancing to the point of favoring the development 
of high=level languages which ae not allow such highly 
machine=dependent features as are found in composite 


languages. 
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Pel sine Pie CANCUAGE 


In the effort to provide comprehensive software support 
for its eight=bit microprocessors, Intel Corporation was led 
naturally in 1975 to the development of the high-level 
language PL/M (29,53). Since then several other micropro~ 
cessor manufacturers have announced either the availability 
or the anticipated availability of PL/M compilers (with pos- 
sibly some slight modifications) for their microprocessors. 
The first large scale application of the language by Intel, 
ironically, was in the development of a sophisticated 
macrosassembler to run on its Intellec 8 microcomputer 
developmental system. 

PL/M is derived from the XPL compilerswriting language 
Mel, which in turn is a derivative of PL/I. Thus PL/M is 
very closely related to both of these languages 1n 1tS = Syn 
warerond semantics. A complete list of the syntactic produc- 
tions iS given jin the Intel reference manual [29], and the 
Syntax and semantics of the C language version used for this 
investiaation is given in Appendix Bb (see file "m.egram")., 
Mt! should be noted that the syntax for the C version is not 
written in the standard BNF notation but rather in the nota- 
tion required by YACC (see Section IV.8B.1). 

There have been many proposals over the years’ for the 
development of machine-inagepentent programming languages 


oe, MeL tlio}, which is also Simitfar to XPL). PL/M, 
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although not currently machinesindependents has the advan- 
tage of having been implemented and used for practical sys7 
tem develooment. Thus PL/M was chosen as the vehicle for 
examining some of the considerations in the development of a 
machinesindeoendent high=level language for firmware system 
design. The remainder of this section is devoted to a brief 
description of the language and a discussion of 1tsS advan- 


tages and ovossibdle shortcomings. 


A. LANGUAGE FEATURES 
Lloyd and Van Dam have aefined a high=level language to 
be one which has the following features: 
(1) Symbolic user variables (allocated by the compiler), 
(2) Ability to evaluate arbitrary arithmetic or logical 
exoressions, 
Flow of contro) stetements beyond simple (condition= 
al and unconditional) GOTO, SKIP, Branch and Link. 
C56 Oia 
In his search for a highelevel programming lanquage, 
Eckhouse found the need for one that was ".e. procedural, 
descriotive, flexible, and possibly machinetindependent." 
mee P.169). PL/M has all of these features, including a 
limited kind of machine=independence. The latter feature 1s 
exhibited in the ability of PL/M programs to be compiled for 
either the 8008 or the 8080 microprocessor. Although these 
two devices are both manufactured ty Intel and have somewhat 
Similar instruction sets, they nave different architectures 
and a sianificant difference in the flexibility and speed of 


execution of their instructions. These points will be ex- 


plored further in Chapters VII and VIII. 
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As iS its oredecessorsr, PL/M is a block=-structured 
language with a comprehensive set of control structures. 
"see (Tlhe control structures of sequential flows, condition= 
a) selection, and iteration are sufficient to implement any 
algorithm." (60, p.35) Sequential flow 1S provided by the 
Simole statement and the DO-END group, while conditional 
selection is accomolished by three constructs: IF*THEN and 
IF-THEN-ELSE statements and DO CASE groups. The DO FOR 
group is used for a fixed number of iterationss and the D0 
WHILE group is used for iterating until some condition 1s 
Satisfied. The GOIO statement is also provided in PL/M~ for 
use In those rare circumStances where the use of the other 
control structures may be somewhat awkward. In recent years 
consioerations of software engineering have discouraged 
indiscriminate use of the GOTO since “... goto-free program= 
ming forces programmers to make explicit the conditions 
under which a given statement is executed, and this can help 
ensure understandability and prevent errors." (Slr peel) 

PL/M 15 relatively easy to learn and read and has a sim= 
ple character set. This latter factor may be important, 
Since a language intended for use in @ wide variety of 
design environments should not require special character 
sets such as those of APL or some of the proposed micropro- 
aramming languages (e.ger see [47)). Ease of learning and 
readability are imoortant In increasing programmer = produc= 
tivity and proaram modifiability and reliability. 

In order to give a more complete picture of the features 
Of PL/M, a Sample program [29] is presented in Figure 1. 
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ie C048: /x 1S the origin of this program */ 
eecdeclare tto literally ‘'e', cr literally ‘!5a', 


L- lf literally ‘Oah', 

a. true literally ‘1l', false literally ‘0°; 
oe 

6.squareroot: procedure(x) byte; 

qs declare (xrvy,2z2) address; 

on y =x, z= Shr(xtl,1); 

9. do while y <> 2, 

0. Va=Z 2a eshictx/y + y + jy 1) 3 
el end, 

ec s return y; 

es end squareroot, 

ec 

LS.eprintSchar: orocedure(char); 

ome declare bitScell literally ‘'91', 
17. (charsi) oytes 

Ve. outout (tto) = OQ; 

| a) call time (bitScell),; 
P10 Clomeae=e OU GuLl 
cls. output(tto) = chars /* data pulses */ 
Pe. char = ror(char,1);7 
C5. call time(biticell); 
eu. end; 
eS. outout Cito) = 17 
2b. cail time lbitt?cell + bitSceili); 
ei. /x automatic return is generated */ 
Ae « end printdchars 
C9. 
S50.printdstrina: procedure(name, length), 
5). declare name adoress, 

Se. (lenath,irschar based name) hyte; 
56. do i = 0 to length —- 1; 

34, Call poramttchar(char()))- 

ne end, 

SS. end printdséstrings 

37. 


Figure 1. Sample PL/M program 
for computing square roots 
(continued on next page) 





S8.printbnumber:s procedure(number,pdaserchars, zerotsuppress)s 
eo. declare number address, 


40. (pase-,charsS,zerotsupnpressSr,isj) byte; 

Gi. declare temp (16) byte; 

ie. if chars > last(temp) then chars = last(temp); 

aD. do 1 = 1 to chars; 

44, J} = number mod base + 'O0'; 

ah. in jee 9! 6 6themmy: = amet 73 

46, if z2zeroSsuppress and 1] <> 1 and number = 0 then 
Oy jor ' '; 

4a, temp(length(temp)-1) = j; 

LOT. Number = number / base; 

50. end; 

ili. call printtstringl.temptlength(temp)-chars,s, chars); 
BC « end orintsnumber,; 

55. 

So,declare i address, 

me. Cre 1iteraviy crvif "% 
m56. heading data (crlfcslfelf, 

Di. ; table of square roots', 
ities crlfteslf,. 

59% '" value root value root value root value root', 
60. "value root', 

i. errt, it); 

Oe. 

63. /* silence tty and print comnuted values *k/ 

64, output(tto) = 13 

65% do 1 = 1 to 1000; 

OO. if 1 mod 5 = 1 then 

oe doz if 1 mod 250 = 1] then 

oo. call printSstringl.heading,s lenath(Cheading)); 
69. else 

a. calle peintsstring(. ters |lt{),e); 

71. end, 

Ue. call orinttnumber(i-10-,6r/true /* true suppresses 
er leading zeroes /); 
74, call printtnumber(squarefroot(ijdr+10-6, true); 

a end; 

76. 

77.declare monitors$uses (10) byte; 

yo.eof 


Figure 1 (continued). Sample PL/M program 
for computing square roots (after (29) ) 
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This program (as well as most other PL/M and C programs 
reproduced in this thesis) is written in lower case charac- 
ters, since this is the normal input mode for the UNIX 
operating systen, which was used for all of the work 
descrived. In addition to the features previously men- 
tionedrs notice should be taken of the comment convention of 
tne language. Since comments can be placed anywhere within 
a program (rather than on separate lines as in FORTRAN), 
self-documentation is encouraged. Although the "/* 4*/" con- 
vention is a little awkward, it has the advantage of setting 
off comments and not discouraging short comments (as does 
the "CUMMENT" convention in ALGOL). 

Fiaqure 2 presents a second sample PL/M program which 
demonstrates another significant feature of the languager~ 
the nested macror~definition capability. While the macro- 
definition concept is certainly not newr there are many 
languages which do not allow macros (most notably FORTRAN 
and ALGUL). Many languages which do have a macro capahility 
do not allow nesting. As can be seen, the macros increase 
the readability of the program, but there 18S another, 
perhaps greater, advantage 1n using them. By USING macros 
the programmer can specify eae items only once in a prom 
Qram (e.qa.- vector sizes and input/output ports) and then 
use the macro names elsewhere in the program to refer to 
those emer Later he can modify his program by merely 
chanaing tne appropriate macro definitions. While the ad- 


vantages of being able to do this are not as evident in the 
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ey * Paper tape reader controller program */ 


Mm 
e 


3.declare forever literally ‘while 1', 


q 

i cdata literally ‘output(1)', 

= €Sitcat literally ‘output(e)', 

6. ccom literally ‘inputle)', 

Te Ecos literally ‘input(3)', 

om rdata liviwers liye simoue Cl); 

3. PSitot In teralVvy -anout (0), 

10, rcom literally ‘output (0)', 

tel” noreq literally ‘not ccom', 

We « acon literally ‘ror €rstateri)', 

13. perr literally ‘*10bD°, 

Pa. badces literally ‘'100b', 

S:, ok lInpeeemoliyew > 5 and cos < 26", 
16. rrdy literally ‘rstat', 

te? s CuK l lveetrar ly to; 

ve. c1lk0 literally ‘'Obd', 

19, drdy literally ‘lo'; 
CU. 
el.declare cps byte, 
Ges wait(ee) byte initial 
oe C2507, e200 mo’, 145, 1e5-,1117100,917037 7/77 iy 
ou, 677,63759,567557,50748745,43,42,40); 
ED « 
eco.do forever; 
Cals cstat = 0; 
20. 
29./* wait until read request */ 

50). do while norea,s 
Bl. end; 

ie. 

33./* determine the characters per second rate */ 
34. cps = cCDdS, 

SD ; 

36. if acon and rrdy then 

Sis dos 

So. if cos ok then /* we are ready */ 
39. dors /k to read characters */ 
40, cdata = rdatay, 

at. reoeom = clkl; 

Ge. rcom = clk0; 

 . ; cstat = drdy; 

Gq, cstat = 0; 

45, /* wait for tape to move */ 

“Wo, call time(wait(ces - 4)); 

Ae end; else cstat = badcps; 

aS. end; else cstat = perr, 

Q9.end; 

50.eof 


Figure e@. Another sample PL/M program 





short program of Fiaqure e@ as they would be in a large pro- 
gram, it should ve apparent that this will increase the 
modifiabilityr, and consequently the reliabilitys of programs 
written in the language. 

Another, less significant, factor which increases freada- 
bility is the inclusion of the separator "3S" in some of the 
long identifiers in the program of Figure 1. This character 
is i@nored by the Scanner in the PL/M compiler when included 
within identifiers and numbers. 

Examination of the PL/M manual [29] and the programs in 
Figures 1 and 2 will reveal that PL/M contains functions 
which relate directly to the Intel 8008 and 8080 instruction 
sets. Thus PL/™ fits the definition given by Lloyd and Van 
Dan for a Go oned language: "A  lanquaqe whose features 
are explicitly designed to coincide (to a large extent) with 
Mmnenw hardware capabilities of its object machine ....”" 
(38, 9.540) Fortunately this is not as serious a drawback as 
it might seem, as evidenced by the fact that other micropro- 
cessor manufacturers are now developing or have developed 
PL/M™ compilers for their machines. All of the functions in 
PL/M which relate specifically to the 6008 and tne 8080 are 
implemented as builtin functions; i.ew.r they are equivalent 
to procedures (and variablesr in some cases) which are de- 
clared in an encomoassing block level hidden from the pro- 
grammer. Lloyd and Van Dam [(38) recoanized that this is an 
important concept, and the method by which it is implemented 


1s explained further in Chapter IV. 
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The builtin function approach is probably preferable in 
firmware apolications to the extensible language aoproach, 
although this will probably be a topic of considerable de- 
oate for many years. An extensible language is essentially 
one which hasS a more sophisticated macro capability than 
/M. It allows the programmer to define new instructions 
and redefine the base instructions of the language. This 
may seem to be a desirable feature, but unfortunately it 
violates the principle of uniformity. Halstead observed 
that "... the extensibleslanguage approach ... seemed to 
open the door to a dangerouss undisciplined proliferation of 
overlaopinag and even incompatible dialects within a single 
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eee POTENTIAL MODIFICATIONS 

In order for PL/M to serve as a useful general-purpose, 
machine~indevendent programming lanaquage for firmware 
design, it will probably be necessary to make some slight 
modifications. The changes described below were sugaested 
by study of other programming languages which are similar in 
Structure to PL/M, with particular attention being paid to 
the C language (49). This lanquage has relative merits and 
Shortcomings when compared with PL/M, but it 18 a good sys- 
tem crogramming language which generates efficient machine 
code for the PDP-11 series of minicomputers. Most of the 
items listed below are convenience’ features rather .than 
necessities. (Of courses, a major advantage of high-level 


languages 1S their convenience when compared with assembly 
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languages.) Many of them were not RO Reno eS in the origi 
nal versions of PL/M, probably because they tend to lead to 
less efficient machine code, but most of them would not be 
difficult to implement and some might even allow more effi- 
cient code to be generated. The optimization techniques 
discussed 1n Section VII.B would be of benefit for those 
features with apparent inefficiencies. 

One major weakness of PL/M is its paucity of data types. 
If the language were to be used as the basis of a firmware 
design system, it would need at least a concept of floating 
point variables in order to be widely accepted. Other 
desiravle data types include string and substrings bits dous- 
ble precisions and complex. It would also be convenient to 
have the capability to define data structures. Implementa= 
tion of some of these various data types would probably sugq- 
gest the need for a few new instructions for manipulating 
them efficiently. For example, double precision arithmetic 
Instructions and string concatenation instructions would be 
useful. 

For algorithms involving array arithmetic it would be 
desirabdle to have the capability to declare arrays of dimen- 
SION qreater tnan one. A related feature 1s the ability to 
declare arrays with variable lower bounds, as in ALGOL W. 

Recursion 1s another feature which PL/M lacks; however, 
this may not be significant for firmware design applica 
tions. Recursion allows compact expression of an algorithm 
but 1S not a necessary feature in a language, Since a recur@ 
sive eau re may be rewritten as an iterative procedure. 
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BesideS, recursion uSually sacrifices execution efficiency 
for programming efficiencyr and qreat care must be taken In 
writing recursive procedures in order to ensure that they do 
mot “blow up.” 

A feature which would prove very usefuls especially in 
large system developments, is the ability to link indepen= 
dently conpiled and tested segments of a program. The 
current Intel versions of the PL/M language do not allow 
this, since the second voass of each compiler oroduces abso- 
lute machine code. The implementation of this feature would 
require the declaration of "global" or “external” variables, 
the redesign of pass ec to produce relocatable object code, 
and the design of a linking loader. 

As will be discussed in Chapter VI-, the trends in digi= 
tal architecture development have encourageds, among other 
features, inclusion of multiple highspeed registers and 
fast increment/decrement instructions. One way in which to 
allow the high=level language programmer to take advantage 
of such features 18 to provide special constructs within the 
language. For exampler he could be allowed to declare fre 
quently referenced variables’to be "register" variables in 
order to increase execution speed (and also produce a slight 
Saving 1nN the amount of main memory required). The program= 
mer could also be allowed to write statements such as 


i = ++j - k; 


in order to take advantage of the increment and decrement 
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instructions. The first statement above would qenerate code 


to mmcrement je Subtract the value of a a from the new 


value of "jr," and store the result in " 


i"; while the second 


Statement would generate code to subtract the value. of a 


0 Lal 


Ve and then 


tt 


from the value. of Jer Store the result in 
decrement "j." 

Both the register declaration and increment/decrement 
features are available in the C language. The 
increment/decrement feature Should be really just a conveni- 


ence for the programmer,y Since the Same statements could be 


written in C as 


and 


and the compiler should generate the same code as for the 
previous two statements (unfortunately it doesn'te-see Sece- 
tion Ut aay le aes The register declaration in C does result in 
more efficient code being generateds howevers, there may be 
other ways to Solve the register allocation problem. This 
point is discussed further in Section VII.B.c. 

Another potential change in PL/M would involve the addi 
tion of the conditional expression. This would enable the 
statement 

if a < b then c = a; else c = b> 
to be rewritten more concisely as 
c = if a < b then a else b; 


and could be done by merely adding a few more productions to 
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the grammar (see Section I[V.8.1). This change would not 
increase the efficiency of the generated code. 

One final area for potential modification involves” the 
CASE statement and will probably require a great deal more 
Study than some of the changes suggested above. The CASE 
Sonstruct in PL/M can be awkward and error-prone 1n some 
Situations, as illustrated in Figure 3a). It should be 
noted that 1t would have been very easy for the programmer 
to incorrectly count the number of semicolons in this. sec 
tion of code. Also he has had to resort to the mucho 
maligned GOTO in order to Share code between two of the 


caseSr and his anly control over an outrof-range value of 


et TH 


c" is to make a test before entering the CASE group. 

Figure 3{b) Shows how the same routine would be imple- 
mented if the C language SWITCH statement were available in 
EE/M. In this "case" there iS no need to count semicolons. 
The use of the GOTO is avoided, since the cases may be list~ 


ed in any order, and the BREAK is used to exit from the 


group. Also there 1s a Specific default case to ensure that 


wt Lh 


appropriate action 1s taken for all values of "c. 
Both the CASE and the SWITCH constructs have advantages 
and disadvantages in comparison with one another. The CASE 
Statement, despite the drawbacks noted above, will produce 
more efficient code in many Situations and should not be 
discarded in favor of the SwIlTCH. Rosser et ale highlighted 
one of the tradeoffs involved when they noted that 
eee to ensure completeness of case statement control a 
programmer should be oermitted by the syntax to specify 


what should hanpen when a case statement variable iS out 
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jee < '8’ ofr c > *u' then call err; 
do case c = ‘a's 
tha . 
togd = true; /x case ‘'d' x/ 
a a ae ea 
do; /x case ')]° xk/ 
1 = true; 
go to tabi 
end; 
tae 
wodo = true; /x case 'p! x*/ 
tae 
togt = true; /x case ‘t' x*/ 
labi: do; Lewcase. U k7 
tim = QO; 
do while (c := getc) >= '0' andc <= '9'; 
lim = lim * 10 + ¢c = '0'; 
end; 
if |} then lim] = lim, 
else limu = Jim, 
end; 
end /*x case aqroup */; 
(a) 
do switch c; 
case ‘d': togd = true; break; 
masse ‘l*: |] = true; 
case ‘u's: lim = 0; 
Gomwini wesc s="getc) >= "0° and ¢ <=" "°9"; 
lan =r * 10+ ¢c = "0"; 
end; 
1f | then Jiml = lim; 
else limu = lim; break; 
case ‘p's togp = trues break; 
case ‘'t‘': togt = trues break; 
default: call err; 
end; 
(b) 
Fiqure 5. Cay PL/M code using the CASE construct, 


(bo) PL/M code usina the SWITCH construct 


57 





of range. Confirmability applied to the same issue would 
imply a proarammer snould be required to state what shoula 
happen. Of courser if he knows that out of range values 
are not possibler this too should be expressibler to  pere 
nit implementation efficiency. f>le Peco) 
Vaughn (58) has suagested that both facilities could be pro- 
vided in the same language in the form of a generalized IF 
statement. A simpler alternative would seem to be to incor- 


porate the structure of Figure 3(b) into the present PL/M 


language along with the CASE statement. 
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IV. PASS 1 IMPLEMENTATION 


Aho and Uliman 3) have suggested that the process of 
compilation iS composed of seven subprocesses: lexical 
analysiSr error analysiS»s vookkeepingsy parsing, translation 
(to an intermediate form), code optimizations, and object 
code generation. While it may be difficult to identify all 
seven of these suboprocesseS IN any qiven compiler and their 
order may not be the same as that givens, this 18 a good con- 
ceptual model. Fiqure 4 shows how each of the parts of this 
model is related to the others [3, p.74). 

This chapter documents the initial stages of the desian 
of a compiler for user=definable architectures. All but the 
‘code optimization and code generation phases of this model 
were implemented. The latter two phases are discussed in 
Chapters VII and VIII, and suggestions are given there for 
their implementation. Recommendations for continuation of 


moe design are given im Chapter IX. 


meee THE FORTRAN VERSION 

In order to gain insight into the analysis of some of 
the problems presented in other sections of this thesis, it 
was felt that some practical experience in compiler imple- 
mentation was desirable. For reasons given in Chapter ITI 
the PL/M microprocessor language was chosen for this) pur- 


poser, and an attempt was made to implement the commercial 
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Figure 4. Model of a compiter (after (3)) 
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FURTRAN version on a Digital Equipment Corporation PDP=-11/50 
computer with an interactive operating system. Unfortunate= 
ly this proved unfeasible, and attention was shifted to 
writing another version of pass 1 of the compiler in a sys 
tem programming lanauage. The latter effort was successful, 
and a full account is given below in Section IV.B. 

The main reason for the failure of the FORTRAN implemen- 
tation was~ that it required more primary memory than was 
available on the PDP=11. When run on the IBM S/560 at the 
Naval Postgraduate Schools pass 1 of the PL/M compiler re- 
quires approximately 120K bytes of memory. On the PDPa-il 
only about 56K bytes of user memory were available, and if 
all of the object modules could have been linked and loaded 
together it is estimated that they would have occupied about 
100-110K bytes of memory. 

An attempt was made to divide the routines 1M SUChH a way 
that several sub-passes could be generatedr, each requiring 
less than 56K bytess howeverrs there turned out to be too 
much interdependence among the routiness, and there was ale 
ways at least one partition which required more memory than 
was available. This was because the synthesis routine (the 
one which generates the intermeaiate language code) reauired 
apout SOK oytes wy itself, and it required many other 
routines to be loaded with it. 

Another problem which developed involved the discovery 
that the data initialization statements in the Intel PL/M 


compiler do not conform to ANSI standard FORTRAN 
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soecifications (although it 18 claimed oa the comp) ler. 1s 
written in Standard FURTRAN to enhance transportability). 
The FORTRAN compiler used for this project accepts only 
programs written in standard FORTRAN, It requires each 
variable initialized in a DATA statement to be named indi- 
vidually,s and this caused problems with the vast number. of 
vectors which are initialized in the BLOCK DATA routine. 
Moms by itself was mot a critical problem and could have 
been overcome without too much difficulty if there had been 
justification to continue working Wer the FORTRAN version. 
After the first attempts to partition pass 1 of the com= 
piler failed, there were two alternatives available. Either 
a8 more concerted effort could have been made to subdivide 
the FORTRAN version, or a completely new version could’ have 
been attemoted in a more efficient language. After consid= 
ering the amnount of effort which would be involved in work= 
ing with the FORTRAN version and the inherent inefficiencies 
entailed in running it on a 1l6=pit machine (Ce.aer it Agee 
32-bit integers) it was decided that it would be simpler and 


more beneficial in the long run to write another compiler. 


Peete C VERSION 

After the FORTRAN version waS abandonedr pass 1 of the 
PL/M compiler was successfully implemented using the com-= 
piler writing facilities supported by the UNIX operating 
System (50). Since a Secondary objective of the project was 
_to develop a system for experimenting with compiler design, 


rt proved worthwhile to utilize these more efficient 
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facilities. Because of the time constraints placed upon 
this project only pass 1 of the compiler was implemented, 
however, much valuable experience was gained in the process, 
and a great deal of this thesis has been influenced by the 
results obtained. 


wee YACC 





For many years compiler writing wasS more of an art 
than a science, but many important developments have taken 
place over the last decade to reverse this situation. Some 
of the most impressive of these developments have been in 
the area of formal language theory and automatic parser gen- 
eration. "The ability to generate parsers from a syntactic 
description of a language 1S an Important conSideration in 
reducing the cost of developing reliable translators." 
[60, p.34) 

The parser generator in the UNIX system 1S Known as 
YACC (Yet Another Compiler"Compiler) (30). It has been in 
use for about two years at Bell Laboratories wheres among 
other thingssr it has been utilized in the development of = an 
easy-to-use language for a sophisticated mathematics 
typesetting system (32). Input for YACC consists of 38 syn 
tactic and semantic description of the grammar of the 
language for which a parser iS desired. Appropriste 
languages belong to the class known as LALR (2,3-,4)5+ or 
look~ahead LR, since they read text from the left, perform a 
right-parse, and resolve conflicts by looking ahead in the 


text stream. This 1S a very broad and useful subset of the 
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context-free languages~sr and one which includes PL/M, YACC 
enecks the grammar for conflicts ands if none exist, pro- 
duces a Set of parse tables for the language. 

The semantics associated with each production in the 
grammar are transformed by YACC into a C program which con- 
tains the parse tables as data. When this program has’ been 
comoiled it 1S linked with a parse table interpreters pro- 
vided by the YACC librarys and any other programs which have 
been written by the compiler designer. Actually YACC pro- 
vides only the core of the compiler=--the parser (which pere 
forms the syntactic analysis function of Figure 4) and a 
means of communication between the parse stacks and the pro- 
Qrams provided to perforin the other functions (Clexical 
analysisSvs error analysiSy, bookkeepings, and coe translation) 
of the code generation process. 

File "m.gram" in Appendix B contains the YACC input 
for PL/M. The syntactic notation is somewhat different from 
the normally encountered BNFse in which a production might be 
written as 

<NONTERMI> 3s3= <NONTERM2@> TERMINAL <NONTERM3> 
rather than the YACC version 
nonterml: Nonterme ‘terminal’ nonterm3 
in which. all terminal symbols are quoted unless they have 
been declared to be terminals (as_ have "identifier", 
"number", and “string" on the first line of "m.egram"). The 
Bonvention of using a wertical bar ("i")Je to indicate the 


beginning of a production with the same left side as the 
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immediately preceeding production has oe retained from 
BNF, The semicolon ("7") 1S uSed to indicate the end of a 
set of rroductions with the same left side. It should be 
noted that a quoted semicolon ("';'") may occur within a 
production as a terminal symbol. 

Semantics are provided by appending an equal sian 
("=") followed by a C language statement (compound state- 
ments are enclosed in braces, "“{" and "}") to a production 
before either the vertical bar or the semicolon. The <tpino= 
cedures used for implementing the semantics of PL/M are dis- 
cussed in Section IV.8.5. 

The extreme flexibility afforded by the use of an 
automatic parser generator such as YACC is demonstrated in 
Figure 5, which Shows the changes required in the PL/M gram- 
mar in order to imolement the conditional expression con- 
mamuct (see Section III.8). Productions 6&6 and 87 are 
Currently included in the compiler implemented for this pro- 
ject, and productions 87a-8/c are the new productions which 


would have to ove added. 


expression: logicalexpression /x 86 */ 

' variable ‘:' ‘=! loaicalexpression /* 87 xk/ 

: ifexpression /x Bla */ 

, 

ifexpression: trueobject expression /x Blb «*/ 

’ 

trueobject: ifclause exoression ‘else' /& (Biers 
; 


Y 
Figure 5S. Potential syntax changes for adding 
the conditional expression to PL/M (see Chapter IIJ) 





gee Vata Structures 

One of the first and most important steps in design= 
ing a complex software syStem 1S the definition of an ap- 
Pmeoprirate set of data structures. The principal structures 
used in the aiumplementation of the PL/M compiler’ are 
descrided below 1n order to aive a fuller understanding of 
the nature of the problem ana insight into the changes which 
would be necessary in order to expand the use of the com- 
piler to a more general environment. The declarations of 
all of the stacks and tadles used can be found in the file 
"“medecl" in Appendix 8. The macros used in the declarations 
are definea in file “m.def.” 

The two most important data structures used in a 
modern compiler are the parse stack and the symbo] table. 
mememerse stack in an LALR parser is used to store input 
tokens for the "shift" and "reduce" operations. In aeneral, 
there are at least two parallel stacks which contain various 
pieces of information about the tokens. YACC provides parse 
Stacks in itS parse table interpreter routines with one 
Stack being reserved for values provided by the scanner. 
The operation of these stacks is rather complex and will not 
be considered herer since Aho and Johnson [2] have provideg 
an excellent survey of the techniques involved. Since there 
was a need to retain more than a single piece of information 
about each tokenr, and there waS NO way tO communicate with 
the parse stacks in the parse table interpreter other than 


to provide a single valuer it was necessary to implement 
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four other stacks for this purpose. The oneration of these 
meeacks 1S discussed in Section IV.8.53. 

The symbol table iS important for a number of rear 
SONSr, not the least of which is the fact that it 1S used in 
conjunction with the intermediate lanquage output to 
Emansmit iaiuntormation to the tater passes of the compiler. 
It usually accounts for the bulk of the main memory data 
storage requirements of the compiler and must therefore be 
implemented in as efficient a manner as possible. 

The symbol table is aevector of eight-bit bytes 
whichs during the Pee of a compilations consists of a 
series of entries of varying types. The format of a general 
symbol table entry for the PL/M compiler is Shown in Fiqure 
one This is the type of entry which is generated for all 
varianblesS and orocedures’ declared by the programmer. 
Reserved words and macro definitions also are represented by 
symbol table entriesr but the formats of these entries. are 
Slightly different from that shown in Figure 6. The differ= 
ences are described below, following the description of the 
general type. 

The first three bytes of the format are common to 
all three tynes of entries and are referred to as fixed 
Eatormation ("finfo” in the programs). fhe first byte con- 
tains the “last” field, which specifies the number of bytes 
to the veginning of the preceding entry and is used _ (for 
chaining downward through the table (Casr e.ges when printing 


or dumping the symbol table). It Should be noted that since 
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Figure 6, 


Format of a general 


table entry 


symbo] 
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the “last” field contains only eight bits each symbol table 
entry 1s limited to 256 bytes, although it will generally be 
much shorter. This in turn ultimately limits the lengths of 
variable and procedure names and macro definitionSr since 
the characters for describing these attributes must fit into 
the remainder of the entry after the fixed information = and 
other fields have util1zed some of the 256 bytes. 

The second byte of the entry contains three fields: 
"type," "precision (prec)d)," and "based (b)." The “type 
field consists of four bitsS and 1S uSed to distinguish among 
Mie various types of entries (variables reserved words mac- 
ro, vectors, etc.). The alternatives can be found in file 
Omedef." The precision field contains three bits and is most 
commonly used to represent the precision (1.@.e, the number 
of bytes required) of variables, vectorss or the result of a 
function procedure call (zero indicating no value returned). 
The “oased" field, if set to "1," indicates a baseds or 
indirectsy variable. 

Next is the "size" fields in the third byte. This 
field 1S used to indicate the length of the following two 
Melos, “name” and “hcoll.” The "name" field contains the 
printname of the symbol and has a lenath equal to the number 
me charecterswmin the name. The “hcoll" field is always two 
bytes long and contains the absolute address of the previous 
Symbol table entry whose printname has the same hash code as 
mimes Symbol (see Section 1V.6.53). Ihus the value of “size” 


1s equal to the length of the printname plus two. 
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During the course of this project it was found that 
Bomonier=generated labels were the only entries which had no 
printnamer and the entries for these symbols conveyed no 
information other than the symbol number (see below). Since 
they only took up precious symbol table space (especially 
for long programSr which already require a qreat deal of 
Space), these entries were eliminated from the symbol table. 
Examination of the symbol table in Figure 8 makes it evident 
which symbol numbers are used for compiler-generated labels, 
since these are the only symbols which do not have entries 
Gewager OCDr ScSr S29). 

Following the "“hcoli" field in the general symbol 
table entry is the “syno" field. This field contains’ the 
symbol number of the entry. Each time a new symbol is de- 
clared by the programmer an entry of this tyove 1S mader Pee 
the next sequential symbol number is assigned. The "“syno" 
field is ten bits longr and thus there can be as many as 
10e4 aifferent symbols in any program Cincluding compiler= 
Memerated labels). 

ine tanaleryvelermim the general entry is the “length 
field, which indicates the number of elements in a vector or 
the number of arguments required by a procedure. In the 
Beeer case “length may be zeros for a procedure “with no 
meogumentS;, Of as large as 63, since a procedure definition 
uses only the first six bits of this field. (This restric= 
tion could easily be changeds however, it is doubtful wheth- 
er any procedure 1n a wellewritten program would have more 
than 63 arguments.) 
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A saving of table space 1S accomplished by classify-> 
ing vectors into two categorieSs short and longr depending 
upon whether or not they contain fewer than 64 elements. In 
the case of short vectors (distinquished from long vectors 
by the pUyee, field) and variables, the byte containina the 
last eight bits of the “length" field is deleted, as dis- 
eussed in Section IV.6.53. 

Figure 7 shows the changes required in the general 
format of Figure 6 for reserved words, macro definitions, 
ame based variebles. As indicateds all fields from “last” 
through pimeo lel: Bean as in the general format. Figure 
7(a) indicates that the entry for a reserved word (e.g., 
"dor" “forrs"” “while") has one additional byte, the "“resno" 
field, containing the reserved word number, which 1S iImpor-= 
tant in the parsing process. Since this field contains only 
eight bits, there can be no more than 256 reserved words in 
the language. Following the "hcoll" field in the entry for 
a macro definition (Figure /7(b)) are the "“msize" and "mdef" 
fields, the former giving the number of characters in the 
moeroition (restricted to a maximum of 255) and the latter 
containing the definition. For a based variable the “baseg" 
field contains a 7 ae and there is a “bsyno" field inserted 
between the "syno" field and the "length" fields as Shown in 
mugure /7{(c). The "bsyno" field contains the symbol number 
of the variable which serves as the base. The six unused 
bits In this type of entry are wasteful, but most programs 


do not contain many based variavnles. 
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Now that the various fields in a symbol table entry 
have been explained, it should prove useful to look at an 
example. Figure 8 shows the symbol table which was con= 
structed by the PL/M compiler for the square root program of 
Figure 1. Each line of the printed table corresponds to one 
entry in the symbol table. The reserved words, which are 
stored immediately below symbol SOs, are not shown in this 
table. It Should be noted that there are no "“syno-" 
Meased," “precision,” or “length” field entries for macro 
Betinitionsss The “name” column of the table contains the 
printnames of all ee and the "msize" and “mdef" fields 
for macros. 

A very imoortant point to note here is that symbols 
SO0-“Se2 were not declared in the square root program but are 
the variables and procedures which relate PL/ZM to the Intel 
8080. These symbols were placed into the symbo) table dur- 
ing the initialization of the compiler and can be considerea 
to have been declared in an outer olock encompassing the 
square root proaram. The manner in which this was done can 
be seen by examining file "memain.c" in Appendix 6B. Since 
it is very easy to change the names and attributes of these 
Symbols in Hee Case it is also very easy to tailor. the 
lanquage to the architecture of the machine for which the 
object code iS to be generatea (See Chapter JII). The mean- 
ings of these symbols need not be of concern during the 
first pass of the compilation but will be important during 


later passes. 





Syno 6 Pr Len Type Size Wame 


SiG? l 105) [2 13 monitoruses 
S60 j 98 i1 9 heading 

j Ogerit 5. cr, | fF 
$58 Z 1 c 34 
SS2 1 15 le 6 temp 
951 j l c 3) 
So ] | c Say 
548 1 1 a 14 zerosuppress 
mi 1 j e 7 chars 
946 j j e 6 base 
S45 e 1 e 8 number 
S44 0 q 6 13 printnumber 
S41 »%* |} ] c 6 char Based $37 
S40 1 ] c Sui 
938 j l a 8 length 
So7 c 1 Yes 6 name 
$36 0 e 6 Loe prime st ring 
$33 1 1 e 34 

| 9 bitcell e@ 91 
931 1 1 c 6 char 
930 0 j 6 11 printchar 
Sel Ps ] c S52 
S26 e | e Ss y 
S24 2 } c 3 x 
S2$ | ] 6 le squareroot 

] 4 false 1 0 

1 6 true 1 1 

j 4 if 3 Oah 

] Chao. 1G 

j Seta O. lyse 


Figure 8&8. PL/M symbol table 
for tne program of Figure 1! 
(continued on next page) 
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Syno B Pr Len Type Size Name 


See 2 1 7 0 

S2} 2 e 8 5 dec 
S20 a 2 8 & double 
obo } } 8 6 move 
$18 } } 8 6 last 
Si1/ } ] 8 8 length 
$1.6 | } 8 S output 
SiS } } 8 7 input 
Se) 1 1 8 Stow 

Srl) 5 1 l 8 6 high 
Ske 0 1 8 6 time 
S11 1 e 8 5 SCE 
Se r c 8 SSC | 

S9 1 a 8 5 she 

$8 1 2 8 5 shl 

S7 | c 8 S ror 

S6 } e 8 > ie ee 

$5 ras i 7 ro staekatr 
S4 1 1 7 & memory 
Si j } 7 8 parity 
Sye 1 1 7 6 siqn 
Sl 1 1 7 6 zero 
30 j } le i east y 


Figure 8. PL/M symbol table 
for the oroagram of Figure 1 (continued) 





Be lhe rarser 

The main function of pass 1 of the PL/M compiler is 
to convert the source language program into a form which can 
be used by remaining stages of the compiler to qenerate 
machine code. The source language program 1S reoresented In 
the computer asa linear string of ASCII] characterS,s orga- 
nized as a series of “identifiers,” "“numbersr" and "strings" 
Beeeeecalled “tokens ). This series of tokens is the “text 
meeeam for the compiler. In order to perform the transia- 
tionr pass 1 must parse the program; 1.eer it must examine 
the text stream and JOO which of the rules of the PL/™M 
meeommor can be applived in order to reduce the tokens to a 
meomcatement Vist" and finally to a "program" (see file 
"megram" in Appendix B). This section contains an overview 
meecne parsing and symbol) tablew functions of pass i. 

hKhen the parser provided by YACC requires a token 
Geom the text streamrit calls tthe user~provided routine 
"yylex." (In this section "user" refers to the compiler 
Beevgner rather than the firmware designer.) This routine 
and the routines which it calls are listed in file 
"mescan.c" (Appendix 8). "“yylex" calls "gettoken," which 
constructs tokens from the input charactersr determines 
which of the three types of tokens (or a special 
Cheracter-"e.ger, commar semicolon) it has founds and come 
Putes a hash code for each identifier. fhe latter function 
1S accomplished by forming the sumr modulo 128, of the ASCII 


values of the nail deme f S in the printname of the identifier. 
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This hash code is used by “yylex" tater fa looking up the 
identifier in tne symbol] table. 

The vector "varc" (Figure 9) is used by "gettoken" 
to accumulate characters from. the Inout Str imno. Several] 
tokens may ve accumulated in "varc" before being used by the 
parserr and the variable "“tokindex” ts used to indicate the 
element of "varc"™ which 1S the beginning of the current 


Paecumulator." The first byte of each accumulator contains 
the length of the tokenrs thus limiting the length of each 
token to no more than 254 characters. Since the length of 
"varc" is normally less than 255, and it may contain more 
than one token, the upper bound on the length of a token 1S 
usually much less than 254. 

Once "gettoken" has completed its functions, control 
returns to "“yylexr," which may take one of several sets of 
actions, depending on the type of token scanned. If an end 
meernle character or other spectal character was Scanned, 
"vylex" returns the character to the parser. If a number 
was scanned, "yylex" reports this to the parser and returns 
@ayemvalue of the number. If either a string or an identin- 
fier wasS sCcannedr "vylex" "pushes" information onto the 
Meer-controlled parsing aoe CP) Guirems 7) « (The stack 
manipulation routines are listed in file "m.saux.c.") In the 
Case of a stringer the stack pointer ("sp") 118 incrementedr 
Evarisep)" iis assigned the current value of “tokindexr” and 
meokindex” 1S advanced to the value of the next free loca- 


tion in "varce." The fact that a string was Scanned is 
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Figure 9. Scanning and parsing stacks 
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" tt 


reportec to the parser along with the eee value orf SD» 
mse discussed in Section IV.8.5. 

The actions for an identifier are Somewhat more com- 
plicateds since the identifier may be a reserved words macro 
call, or proarammer-defined WOrd. In order to determine 
which case is applicable, the identifier is looked up in the 
symbol table by finging its address in the element of the 
vector "“hentry" given by the hash code computed by “getto- 
ken." If the address is other than the zeroth element of the 
symbo]| taole, the printname stored in “varc” 1S compared 
with tne printname stored in the table entry. If the names 
do not matchr the value of “hceoll" is used as the next ad-~ 
dress in the search. This process continues until either a 
match is found or the current value of "hcoll" is the ad~ 
dress of the zeroth element of the symbol table. If oan 
entry for the identifier is located in the symbol table, the 
"type" field is examined to determine whether it is a 
reserved word or a macroe In the former caser the reserved 
word number iS returned to the parser. In the latter case, 
the scanner 18 set up to begin reading input characters from 
the "mdef" field of the symbol table entry, and "“gettoken" 
is called again. 

If the identifier 1s neither a reserved word nor. a 
macro, information about it is "nushed" onto the parsing 
Stacks in the manner discussed above for strings. In addi-~ 
tion to the information stored in “var,s" the address of the 


symbol table entry is stored in "“symlocs" and the hashcode 
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Peocored smesiihesh” (C(see Figure 9), The “fixv" stack is 
used to hold other types of information during the parsing 


process. The fact that an identifier was scanned 1s report- 


D ] + 


ed to the parser along with the current value of SPDe 


If the symbol table Search 1s unsSuccessfulsr an entry 


must be made using the routines in file "mesymec.”" The entry 
is made immediately following the most recent previous ens 
try. The incon field of the new entry is Set to the value 
of "“hentryfhashcode]", and the value of “hentry (hashcode) " 
1s changed to the address of the new entry. It 1S assumed 
at this time that both parts of the “length” field will be 
required. If it 18 diScovered (during the parsing of later 
Mext) that only the first six bits of the "length" field are 
Meedea, the “compress” routine (file “m.Sym.c") must be 
called to remove the extra byte 1n order to save space in 
the table. 

The parser itself uses tables generated from the 
grammar (file “m.egram") by YACC in order to perform the 
translation from the source language to the intermediate 
language (see Chapter V). It does this by shifting tokens 
Onto a set of parsing stacks hiaden from the compiler 
designer. when the tokens match one of the rules of the 
Qrammafr a reduction 1S mage by replacing the tokens on the 
Stack with the symbol on the left side of the rule (or pro- 
duction). The methods used for detecting and recovering 
from errors in the input and the techniques for generating 
the intermediate language code are discussed in the next two 
sections. 
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4. Error Recovery 

ine tmemenmiscussion of the scanner ig, Secttom IV.6.3 
it was assumed that the input stream constituted a valig 
PL/M orogram. Untortunatelys this iS not always the case, 
especially in the early stages of program development. In 
addition to the other tasks which a scanner must perform, 
therefore, it must be able to detect errors and report them 
to the programmer. One SIRE c of a good compiler is its 
ability to accurately report all program errors. 

Debugging of a large program would be greatly inhib= 
ited if the SoA Meo terminated after the detection of a 
single inane: Thus it 1S desirable for the scanner to have 
error recovery mechanisms which enable it to continue poro- 
cessing after detecting and reporting an error. The error 
handling and recovery techniques included in the YACC ver- 
sion of the PL/M compiler are discussed in this section... 

There are three basic kinds of errors which may 
appear 1nN a program=-logice syntacticr, and semantic. rove We 
errors are errors in the programmer's thought processes 
which cause him to write statements which do something other 
than what he intended. For exampler he might write an exe 
pression incorrectly or use the wrong indexing variable when 
working with a vector. It is impossible for a compiler to 
detect errors of this type unless they also result in syne 
tactic or semantic errors. 

Tyee ele CmnOns Team trom themsviolatiron of the 


grammatical rules of the language. The rules for a 
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programming language like PL/M are given in terms of a 
Series of productionss, as in file "megram" in Appendix B. 
One of the main advantages of uSing a parser derived from 
such a grammar 1s that 1t immediately detects and reports 
Syntactic errors. 

Semantic errors are errors which do not violate the 
rules of the language but which do not have any meaning (or 
have an incorrect meaning) 1n the language. It 1s easy to 
write nonsense sentences 1n English which are grammatically 
Gaerrect. An example of a semantic error in @ programming 
language 1s the use of a variable before it 1S "Gee larec- 
Some lanquages allow thiSr but in the current YACC version 
of the PL/M conpniler this 1s not allowedr since proper sym 
weeeecoble entries are made only for declaration statements. 

At this point it should be helpful to look at= an 
example. Figure 10 lists the sample PL/M program of Figure 
1 with several errors intentionally introduced. When this 
program was run through the compiler the output was as shown 
in Figure 11. It should we noted that there are two basic 
types of errors identified in the output. Syntactic errors 
are identified by the term “Syntax error," while Semantic 
errors are identified by the term “compile error." 

In order to allow the parser to continue scanning 
Be input after a Syntactic error is encountered, YACC al- 
lows an SPER: Production to be included in the grammar. 
meoduction a nem Cacia sim Appemarx 1S the error 


production used for the PL/M compiler. In tise  pROGUCc C10n 
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Laenrovrecwn = 
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@ 


10. 
mt. 
ING « 
> 
ee 


CuaS: 4k 16 the origin of this program x*/ 
maeciare ttoO laterally ‘c', crmliterally 


lt literally ‘Oah', 


true literally ‘l', false literally 


esquareroot: procedure(x byte; 


declare (xryr2z) address; 


Vs xX pee = SC ct eles 
do while y <> 2; 
Y = Z; 2 = shrlx/y + y + I, 
end; 

return y 


end squareroot, 


1S.printichar: proceoure(chanr); 


1); 


team declare pitsdcell literally ‘91', 
Wy. cena oyte-: | 

ne . Ouemuc Ct te) —=—0, 

19. call time (bitScell); 

20. oe i= s Ontos, 

el. outout(tto) = chars /* data pulses */ 
Ce. enact = morlchar, |); 

5. call time(€bittcell,; 

e4. end; 

ED SuUtLnuUt Cito) = 917 

ZO. Call time (bitScell + bitiScell),; 
els /* automatic return is generated */ 
e&. end printichar,s 

C9. 

30.printséstring: procedure(name,length), 
31. declare name address, 

3e. (lengthrirschar based name) byte; 
4. Gomy = Onto lemotn = | 

34, call printSdchar(char (i); 

>. end; . 

BD . ena printsstring;s 

S/. 


Figure 10, PL/M sauare root 
program with errors 
(continued on next page) 





38.printsnunber: procedure(number,base,chars,zerofsuppress), 
So. declare number adoress, 


Go. (base,charsS,z7erofSuppressSrisj) byte; 

Qi, declare temp (16) byte; 

uc. Mimenomcee moist (tems) then chars = lastctemp); 

43, do 1 = 1 to chars; 

“ad, j = number mod vase + '0'; 

>, 1f j > ‘9 then j = j + 7; 

46, 1f zerossuppress amd 1 <> 1 and number = 9 then 
‘a ae 

ae . temo(lenqth(temp)-i1) = j; 

49g, number = number / base} 

50. end; 

le call printtdstrinal.temptlength(temp)-charss, chars); 
Dic e end printdénumber,; 

D5. 

S4.declare 1 address, 

De crlf literally ‘crelf', 

BIO « heading @atamcer) ¢ yall f+ 

Dis « : table of Square roots', 
56. Grit, if; 

59. *" value root value root value root value root', 
60. " value root', 

Si. crlfslf); 

62. 

oS. /* silence tty and print computed values x/ 

64, output(tto) = 1, 

65. dom = 1) to 1000; 

66. ft 1 mod 5 = 1} then 

Olt « dor if 1 mod 250 = 1 then 

oo. call printistring(.heading,slenath(headina)); 
69. else | 

WO. Cat) sor imestrina (. (cr, Ife); 

fl end; . 

ec « call printtnumber(1,10,6r/,true /* true Suppresses 
as. leading zeroes t/); 
ya. call printsnumber(sSsquaresroot(i).10-,6, true); 

E> « end; 

on™ 

7/.declare monitorduses (10) byte; 

78.eo0f 


Pigeeem Om Ccomtnucd J. PL/M 
square root program with errors 
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Syntax errorr tine 6% on input: byte 

Syntax error, line 13, on input: end 

Somoilie errorr tine 20 : variable undeclared 

compile errors line ev 3: identifier cannot be a variable 
Syntax errors line e23r on inputs: 3 

Syntax errorer line 347 on input: call 
Semprile error, tine $5 3: identifier required 
syntax errore line 36, on Input: end 

Semele error, jine 46 ; variable undeclared 
Syntax errorr line 46, on input: identifier 


e 


Syntax errors line 70¢ on inputs 7; 


Figure 11. Compiler output 
for proaram of Figure 10 


weremwe Be Ge eseaegu2dewnrwwwvwueenwreeweeeeweeweae @®e sFe»uvw eeu sere wTFew eae FP ee@Fwwewerztesr wee» a wow @ @ = w= 
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"error” iS a reserved terminal Symbol name, and it causes a 
Beate to be included in the parser which will be entered any 
time an invalid symbol 1s scanned. 

When an error iS seen, the currently active states are 


poppeds one by oner until a state 18 reached which has a 
Shift on error. This Shift 18 then doner ana the  reduc- 


tion performed, The user may specify an action, to do 
things such as position the input string and repair the 
symbo] table. After this reduction is doner a flag 15s 


Set, and the parser remains in error state until three 
input SymbolS have been Successfully shifted. If an error 
takes place when the parser 1s Still in error state, the 
input symbol 18 discarded and no new message 1S produced. 
iO, p.~1 5) 
The reason for discarding input symbols 1f an error occurs 
while the ovarser is still in error state 1S to. prevent a 
Simple syntactic error from causing an inordinate number of 
misleading messages to be generated. Of course, if there 
are any actual errors in the text while the parser is in the 
error state they will be ignored. For example, in Figure 11 
it can be seen that the parser discovered an error at the 
beginning of line 54 when it encountered the symbol "call" 
without scanning a semicolon. Figure 10 shows that there 1s 
a missing parenthesis at the end of line 344 ang this” was 
not detected by the parser, since it was still in error 
State. This iS not a@ serious problem, since the parser 
would detect this error on the second compilation attempt, 
after the errors detected on the first try were corrected. 
The error production used in this compiler causes 
the parser to scan until finding a semicolon before attempt- 


ing to continue oarsing. This was found to ve an effective, 


although simple, error handlinaq technique. The actions 
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which must be taken to aliow parsing to continue without 
overflowing the various stacks and tables can be seen by 
examining the listings in Appendix 58. Since PL/M is a 
Statement oriented language Vet than a card oriented 
language (such as FORTRAN) and statements are usually rela-~ 
tively short, most errors will be detected by this scheme. 
In future work: it might prove beneficial to explore addi- 
tional schemes, such as Scanning to a comma or ae close 
NDarenthesis. 

The actions required for detecting and reporting 
semantic errors are not aS easy to specify as are those for 
Syntactic errors, Since they are Scattered througnout the 
grammar. For each production in the grammar the compiler 
Gesigner must consider the meaning of any actions which are 
to be taken and what circumstances will will) cause the ac~ 
tions to be incorrect. For example, the discussion in Secm- 
tion IV.B.2 points out that a procedure may have no more 
than 63 arguments. Thus the actions associated with the 
parsing of a "parameter list" (production 42 in file 
"negram") must include a check for the number of arguments. 
puemee it 1S very difficult to check all possible error con- 
ditions of this typer semantic errors are much more diffi- 
cult to detect effectively than are syntactic errors. In 
Figure ll, for examoler it can be Seen that the error. on 
line 20 ("o0" in place of "0") causes a redundant error mes- 
sage to bewgenerated. Improvement of the semantic error 
detection and reporting mechanisms in this compiler would be 
a worthwhile undertaking for future work. 
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| 
C 


semantics ang Code Emitting 

The metnod for converting semantic actionsSr provided 
by the compiler designer, into a C language program is dis- 
@ussed briefly tin Section IV.8B.1. In order for the action 
Statements to communicate with the parserry a special nota-~ 
tion using “"S" variables is employed by YACC. An example of 
this notation may be seen dy examining the action statements 
Sessociated with oroduction 76 in file “m.qgram" (Appendix 6). 
Each symbol on the righthand side of a production (to the 
muont of the colon) corresponds to a pseudo-variable, the 
name of which is composed of a dollar sign followed by a 
digit indicating the relative position of the symbol tin the 
production. Thus "identifier" has the corresponding 
pseudo-variable "$1" in production 76. There is always one 
and only one symbol on the leftshand side of a production, 
and it has the corresponding pseuaorvariable "ti" associated 
With it. The “S" notation is a convenience for the compiler 
weemoner, and all pseudo-variables are converted by YACC 
Into actual C language variables before compilation. 


In (Sieestiory I V .Bsibasnt is Stated that the current 


¢ ¢ 


value of Sp 1S passed to the parser when an identifier 


Cother than & reserved word or macro) 41s scanned. Any such 
information passed oy "yylex" to the parser may be accessed 
in the action statements by referring to the appropriate "3" 


variable. Thuss 19 production 76, the value of "Si" is the 


value of “sp” received from “yylex." This value is~ first 


“passed as. an argument to the procedure "symcheck" (file 
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memeact.c")J», which checks to see if the variable has heen 
previously declared. Since production 76 is only aoplied 
during the parsing of declaration StatementsS,r this ‘comst)-— 
tutes a check for a semantic error--the redeclaration of a 
variable within the same block of the PL/M program, The 
next three statenents are executed if this 1S the first time 
the variable is veing declared in the current block. First, 
the value of “fixvisp]" is set to zero to indicate that this 
iS not a based variable. The next statement ("$% = sytop") 
is used to communicate to the next Production (possioly 72) 
the location at which the Symbol] table entry for this vari-r 
Sore begins. The third statement calls the "enter" routine 
(file "mesymec") to actually make the entry in the symbol 
table. Whether or not an entry is made in the symbol table, 
the final statement is executed to clear the information 
associated with this variable from the user-controlled 
Stacks. The parser then makes the reduction indicated by 
production 76 and stores the information associated with 
me in One Of its parse stacks. 

An example of a production which causes intermediate 
language code to be emitted can be seen in the action state> 
ment associated with production 96. In this statement, "32" 
refers to a value received from a previously applied produc- 
mmom (one of the set 97-102). The “emit" routine (file 
“meact.ec") iS called with two arqumentS,r the first giving 
the prefix C"OPR") and the second giving the operator deter- 


mined by the value of "$e" (see Appendix A). The "emit" 
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routine writes the information onto a disk file which may be 
used oy later stages of the compiler to generate machine 
code. 

It should be noted that the actions associated with 
production 79 also write information to a disk file using 
the “putw" routine provide by the C language library. This 
second output file is used to Store all “initial” values 
declared in the PL/M program being compiled. 

One final DO in t can be made by considering the ac- 
Bom Statements associated with production 33. Productions 
such as this are ean Chee with the flow of control state- 
ments in PL/M, ana they cause compilers-generated labels to 
be produced i1n- order to effect proper branching. Since 
these labels are often not generated in the Same sequence in 
which they must appear in the intermediate lanquage code, 
Drere has to be a mechanism for storing them until they are 
emitted. As in the case of production 33, labels are aen-~ 


erated by incrementing the variable “nsym." Code for a con- 
ditional branch is emitted at this points, but the label must 
be saved until the remainder of the code around which the 
branch occurs haS bveen generated. This 18S done by calling 
the "“spush" proceaure (file "“meact.c"), which pushes” the 


' In order to save space in the com~ 


eel onto the "cstack.' 
Meee, the =cstack”™ is actually mot a separate stack but 
rather an area at the top of the space allocated to the sym- 
bol table. 

There are obviously many more details concerning the 


performance of this compiler than can be presented here. 
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The YACC reference document (50) should De consulted for a 
more complete discussion of the capabilities of YACC, ang 
the program listings in Appendix B should be studied in or- 
der to determine how these capabilities were aoplied to the 


meyhM compiler. 


71 





Ve. THE INTERMEDIATE LANGUAGE 


eee FUNCTION 

A very important concept in the design of a compiler for 
user-definable architectures is that of the intermediate 
language. The compiler model shown in Figure 4 assumes that 
the source program will be translated to an intermediate 
form, although it is certainly Bee ei oe to design a compiler 
which translates directly to machine code. In fact many 
compilers have been designed in tne latter wayr but they 
lack transportability and are not abdle to easily take advan- 
tage of the more advanced optimization techniques. 

The idea of using an intermediate lanquage dates back at 
least as far as 1958 when there was a discussion of the need 


for a universal computerzoriented lanquage CUNCOL ) in some 





of the early issues of the Communications of the ACM 


fe, 54,55). The intent was to have the UNCOL serve as an 
intermediary between high-level languages and machine 
languages. This would allow a compiler writer to concen= 


trate on translating from his’ highlevel language to the 
UNCOL without worrying about the machine code considera- 
tions. beewoulid also alifowla system programmer for a given 
machine to write a generator program which produced the best 
machine coder independent of the high-level language. When- 


ever a new machine was obtained at a computer installation 
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only the program which translated from UNCOL to machine code 
would have to be changed in order to continue using the 
mran-level languages which had been used previously. Old 
programs could be recompiled without changing the source 
language. Similarly, whenever a new lanquage was desiaqned 
it woula be necessary only to write a translator which could 
convert programs written in the new language to UNCOL pro- 
Grams. The new language would then be available to users of 
any comouter for which an UNCOL=nachine code translator hada 
been written. 

No such universal ote has ever been developed, but 
the concept of an intermediate language has been used by 
many software designers in writing compilers which could 
generate code for computers with different architectures and 
Mrermeruction sets (e.g.r the PL/M compilers available from 
Meee tl for the 6008 and 8080 microprocessors). The fact that 
an intermediate language 1S USeTUl” 1m Comor1rling for usec= 
definable architectures is verified by the use of such a 
mechanism by those who are trying to design high=level 
languages for microprogqrammable machines (18,47). 

The main function of the intermediate language in the 
PL/M compiler is to serve as an information transmission 
medium between pass 1 and succeeding passes. In this role 
it is complemented by the symbol table (Section IV.6b.e2) and 
mime initial value file (Section I]V.8.3). The symbol table 
transmits the names and other attributes of the symbols used 


in the high-level program, the initial value file transmits 
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the initial values of variables which are to be initialized, 
and the intermediate language carries information about the 
actual program steps required by the algorithm. Other in- 
formation may be contained in the intermediate language 
coder @eGer the line number markers which are helpful in 
oroviding gjood diagnostics and information to aid the pro-~ 
grammer but are not really needed for the code generation 
process. 

peendes its use in transmitting information the inter= 
mediate language may have an important role 1n the process 
o f debugging and simulating the actions of programs 
translated by the compiler. AS explained in Section V.b6 
below, the intermediate language code for the PL/M compiler 
can be see eee to be the “machine code" of a mythical 
stack machine. I1t would not be difficult to write an inter= 
preter which could read this codé and simulate the actions 
of the mythical machine in order to help the programmer 
debug his high-level language program. Broca and Merwin [9] 
have devoted a oaper to this topicrs and Reigel and Lawson 
(48) have indicated that this could provide an important 


mactlity. 


feet POLISH REPRESENTATION 

The intermediate language code for the PL/M compiler is 
based upon postfix Polish notation (374¢re2r4e)- The reason 
for using this type of intermediate language iS demonstrated 
in Figure iés which shows how an expression written in infix 


Calgenraic) notation would be translated. The bottom-up 
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Gee= ne Ot 1G Any 


Ca) 


ab* cadak + r- € 


Cb) 


VAL a 
VAL b 
OPR MUL 
VAL Cc 
VAL d 
Cia MUL 
OPR ADD 
ADR ce 
OPR STO 


(d) 


Pyioqure te. Example of Polish intermediate language code 
(ad infix exoression, (bd) equivalent postfix expression, 
(c) tree representation, (d) intermediate language code 





parsing process for the infix expression in Figure 12(a) can 
be visualized in the tree structure of Figure 1i2lc)y, which 
iS a two-dimensional representation of the postfix expres 
yom in Figure idef€b). Thus the ee ee language code 
of Figure le(d) results naturally from the parsing of the 
infix expression. Noteworthy is the one~to-one correspon= 
dence between symbols in Fiqure iec(b) and lines of code _ in 
Figure ie(d). 

ihss type of intermediate language reoresentation is 
usually discusseaq in texts on compiler theoryr but the 
pmresentations usually a not provide many details about the 
methods used for an entire practical program. OUften the 
discussion 18S limited to the type of information presentea 
in Figure 1l2r but operators other than the simple arithmetic 
type are required in a lanquage designed to represent rea] 
programs. For exampler operators are required for branch- 
1NQ, sudscriot calculation, and stack manipulation. The 
complete list of intermediate language prefixes and opera- 
tors used 1n the PL/M compilerr along with their meanings, 
is given in Appendix A. 

In order to provide an example of how the tntermediate 
languaae 1s used to represent a program, Figure 13 presents 
part of the code generated by nass 1 of the PL/M compiler 
for the square root program of Figure 1. The symbol table 
for this program can be found in Figure 8. Noticeable in 
this figure are the expansion factor and the loss of under= 


Standability apparent in going from the high=level language 
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Pircure. 15. 


program of Figure t and symbo] 


LIN 
ely 
OPR 
LIN 
LIN 
LIN 
LIN 
LIN 
OF k 
VAL 
OPR 
Der 
LIN 
LIN 
VAL 
ADR 
OPR 
VAL 
LIT 
OPR 
OPR 
Lit 
OPR 
VAL 
OPR 
ADR 
UPR 
LIN 
Die 
VAL 
VAL 
OPR 
VAL 
OPR 
LIN 
VAL 
ADR 
OPK 
VAL 
VAL 
OPR 
VAL 
OPR 
LIT 
OPR 
OPR 


S25 


S24 

S26 
STD 

924 


ADD 
ARG 


ARG 
oi 
BIF 
Sed 
STD 
9 
S28 
S26 
Se / 
NEQ 
S2y 
TRC 
10 
Sel 
S26 
STD 
S24 
S26 
DIV 
S26 
ADD 


ADD 
ARG 


Intermediate 


8 0 
0 1 
0 1 
Oe! 


language code for the 


table 


of Figure 8 


{continued on following pages) 
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LIT 1 0 1 


OPR ARG 
VAL S9 
OPR BIF 
ADR Sel 
OPR Sip 
LIN 11 
VAL $28 
OP R TRA 
DEF S29 
LIN le 
VAL S26 
OPR Real 
LIN 13 
OPR END 
OPR DRT 
DEF 52.) 
code for lines 14 = 53 omitted for brevity 
LIN 54 
LI 55 
LIN 56 
VAL S59 
OPR TRA 
OPR DAT 
DEF S60 
et 13 0 OD 
LIT 10 0 A 
Ee eet § 10 0 A 
ali LG) 0 A 
LIN 5/7 
Ee) a 9 0 9 
eel 9 0 9 
bd]: 9 0 g 
ee al | 9 0 9 
LIT 9 0 9g 
LIT 9 0 9 
Lif S2 0 20 
LIT 116 0 74 t 
Lait 97 0 61 a 
LIT 98 0 62 b 
LIT 108 ORG ! 
LT 101 0 65 é 
LIT 32 0 20 
ely lee 0 OF O 


Pee is. Ccontinued) 


L1| 10e 0 66 f 
eae 32 0 20 

El 115 O73 S 
LIT 113 0 71 Q 
El bi? 0 aS u 
LIT 97 0 6] a 
Lil 114 0 72 r 
LIT 101 0 65 e 
LIT 3e 0 20 

LIT 114 0 7e r 
LIT 111 0 6F O 
LIT 111 0 OF O 
LIT lio 0 74 t 
LIT 115 0 73 S 
LIN 58 

LIT 13 0 OD 

LIT 10 0 A 

Ely 10 0 A 

LIN 59 

LIT Se 0 20 

LIT 1186 0 76 V 
LIT 97 0 61 3 
Ey 108 0 6C | 
oe ae 117 075 u 
LIT 101 0 65 e 
LIT 32 Ore 0 

LIT Bie 0 20 

LIT 114 0 7e r 
LIT 111 0 6F O 
L1y 111 Viel a fe) 
LIT 116 0 74 t 
Cit se 0 20 

Lig 118 0 76 V 
bit 97 0 ol a 
LIT 108 0 %6C | 
Lil ae ae 0 75 U 
Ei 101 0 65 = 
LIT Se 0 20 

LIT $e 0 20 

LIT 114 0 72 r 
LIT Lili 0 OF fe) 
LIT ae 0 6F O 
LIT 116 0 74 t 
LIT 32 0 20 

LIT 118 0 76 V 
LIT 97 0 61 3 
LIT 108 ORGE | 
Gy 117 0 75 U 


Figure 13. (continued) 





ey 101 0 65 e 
LIT 3e 0 20 

LIT Se 0 20 

ier 114 0 72 r 
LIT 1141 0 OF re) 
Po af 111 0 oF fe) 
ey 116 0 74 t 
Era SZ 0 20 

mel 118 0 76 Vv 
ay 97 0 6] a 
Edy 108 0 6C ] 
aie If 117 Coes U 
LIT 101 0 65 e 
ele $e 0 20 

et 3e 0 20 

eit 114 0 72 r 
LIT al OOF O 
ye 111 0 6F fe) 
LIT 116 0 74 i¢ 
LIN 60 

LI] 3e 0 20 

LIT 118 0 76 Vv 
LIT 97 0 61 a 
LIT 108 0 6C 1 
Cit ay 0 75 U 
LIT 101 0 65 e 
bat $e 0 20 

ely 32 O20 

eT 114 0 7e r 
LIT ee 0 OF re) 
ef 111 0 6F re) 
LIT 116 0 74 t 
LIN 61 

ale 13 0 O 

i GE | 10 O A 

LIT 10 0 A 

OPR DAT 

DEF $59 

LIWN 6e 

LIN 63 

LIN 64 

Laer e 0 2 

OPR ARG 

aT l 0 1 

OPR XCH 

UPR S FD 

LIN 65 

og S| 1 0 1 


tere oe (continued) 
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ADR 
OPR 
DEF 
VAL 
LIT 
OPR 
VAL 
OPR 
LIN 
VAL 
LIT 
OPR 
LIT 
LIN 
OPR 
VAL 
OPR 
OPR 
VAL 
bel T 
OPR 
dl 
LIN 
OPR 
VAL 
OPR 
AUR 
OPR 
OPR 
VAL 
OPR 
VAL 
OPR 
OPR 
VAL 
OP R 
LIN 
LIN 
VAL 
OPR 
Die 
VAL 
OPR 
UPR 
els 
eset 
Lil 
OPR 


958 
STD 

$61 

958 


1000 Sco 


LEQ 
S62 
TRC 


958 
REM 
67 
EQL 

S63 
TRC 
ENB 

958 


REM 


DAT 


Figure) 15. 


5 0 & 
1 oo 1 
250 0 FA 
Peo 
i emp 
io Oo A 


(continued) 
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DtF 
OPR 
LIT 
OPR 
VAL 
OPR 
DEF 
LIN 
OPR 
LIN 
DEF 
VAL 
tak 
Lit 
OPR 
Lil 
OPR 
LIT 
LIN 
OPR 
VAL 
OPR 
Liv 
VAL 
OPR 
VAL 
OPR 
OPR 
eal 
OPR 
Lit 
OPR 
LIT 
OPR 
VAL 
OPR 
LIN 
VAL 
OP R 
AUR 
OPK 
VAL 
OPR 
DEF 
L iin 
LIN 
LIN 
LIN 


ARG 


73 

ARG 
S44 

PRO 


958 
ARG 

S23 
PRO 
AKG 


ARG 


Figure ee 


2 Cre 
10 0 A 
6 0 6 
1 Oe! 
10 0 A 
6 0 6 
l 0 | 


(continued) 
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to the  intermnediate language. Of Scourse the computer; 
through tne actions of the compiler, 1S much better equipped 
to cope with this than the human programmer trying to write 
this program in assembly lanauage. 

The postfix Polish code 18 often referred to as zero- 
peenmess code since the operator instructions are intended to 
manipulate values on the top of a pushdown stack ana thus 
do not contain an address field. i iemne Chica Genero i yes stised 
Boe generate mechine code from this zerortaddress code 1s to 
Simulate a mythical stack macnine iN the compiling orocessS. 
This “metaz~execution" stack of course does not usually con- 
tain values, since most of the variables 1n @ program have 
values assigned at execution time rather than at compile 
timer but rather it contains information about the proaram 
Symbols. This type of code generator is fairly simple to 
implement, especially if optimization is not too important, 
and should be ieealay, Cos eco ecco oma tebrerdni) ven scene 
Boee Chapter VIII). 

mecnould be noted that each “instruction” im the inter= 
mediate language consists of two parts, a prefix and an 
Operator or operand. The prefix indicates the type of the 
instructions while the second part iS an operator (le.aer 
MUL, ADD, TRA) for an OPR prefix or an operand for other 
prefixes. The LIN instruction is used to transmit line 
numbers from the source programr and the DEF instructions 
Bene labels in the imtermediate code for osurposes of 


Eranching. The VAL and ADR instructions place values and 
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addresses, resnectivelyr on the stack, while the LIT in- 
Struction places literal (numeric or immediate data) values 
on the stack. The second field of the LIT instruction 1s 
presented in four columns in Figure 13. The first column 
Qives tne decimal value of the 16-bit literal (range: 
0-05555), and tne second ee third columns give the hexade- 
cimal values of the nigh and low order byteSr respectively. 
Ihe fourth column indicates the two ASCII characters (Cif 


printable) represented by the value. 


Pee OTRER REPRESENTATIONS 

The reverse Polish form is not the only. Bite used for 
intermediate representation of programs. The two most com= 
monly used alternatives are triples = and quadruples, the 
former being equivalent to twormaddress code and the latter 
to three-address code. Using this terminology, the Polish 
code could be referred to as "Singles." 

Triples ape Mone  Creamly GTepresentative of the ~tree 
Structure of a program than zerowaddress coder since each 
triole has the form 

Covoerator, operandl, operande), 
Smoetne triples are linked by pointers to Show the flow of 
control (either operand may actually be a pointer to another 
triple whose result is used in the current triple). One 
difficulty with this method is that it requires more memory 
Peerepresent the program than the Polish method, but Gries 
icc} presents a method for modifying the implementation to 


reduce the memory requirement. 
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Quadruples have a "“result" field in addition to the 

three fields of the triple and take the form 

(operator, operandi, operande, result), 

where the fourth field 1S either a temnorary variable gqen- 
erated by the compiler (in the case of a subexpression of an 
arithmetic expression) or a program variable (e.a., the 
variable on the left~hand side of an assignment). Some qua-~ 
druplies Cand triples also) will require only the operator 
and one operand (e@.Ger a branch instruction), while cnere 
Mil Fequire all fields but "operande” (e.g., for the unary 
minus operator: y = ~x ==> CX) eves The difficulties with 
quadruples are a greater memory requirement than for the 
Polish form and the large number of temporary variables 
which would be generated for any significant program. 

Many compiler designers prefer triples or quaduples to 
moersh code 116,40,41)+, because these forms are claimed to 
be easier to manipulate for optimization ourposes. This 15 
a point which deserves further investigations however, et 
Should be noted that powerful optimization techniques have 
been successfully applied to programs represented by a Polo 


ish intermediate language CLST 
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Vij Cl i vemoroten UB SCRIP iON 


Unce the source program has been translated into an 
intermediate form and its descriptive information has been 
preserved in tabdlesre the job of converting tnis information 
into control code begins. The remaining stages of the come- 
piler require,r IN addition to the information transmitted 
from pass i, detailed knowledge of the architecture and 
instruction set of the hardware in order to accomplish the 
code generation task. Ordinarily this other information 
would be included in the remaining stages at the time the 
compiler was desianed, but this cannot be done if the archi- 
tecture 1S unknown prior to compile time. Thus this chapter 
is concerned with the types of information required and the 
oroblem of describina this information for varying architec= 
tures. 

Many languages have been developed for describina digi- 
tal systemsr and two excellent surveys of these J]anaquages 
have been published [6,25). Because most of these lanquaages 
were developed vy individuals or small groups of individuals 
working on specific problems they have shortcomings which do 
not allow universal aonplication. For this reason the 
Conference on Digital Hardware Languages, a special continu 
Ing conference of experts 1n the computer hardware descrip-= 
tion fielder, has been formed in an attempt to define a 


language which can become a standard for the industry C37) 2 
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Althouagn the main purpose of such languages is to serve as 
aids in designing and simulating digital systems, it Should 
be obvious that they could also be used to describe a system 
as part of the compilation process. 

Since there are several levels of detail which may be 
used to describe a digital system the first problem i1s_ to 
choose the most appropriate one. Bell and Newell (7) have 
defined a hierarchy of five levels for description of com-= 
puter systems: the circuit levels, the switching circuit lev- 
ely the register transfer (RT) levels the programmina level, 
and the PMS (processorr memory, switch) level. .The circuit 
level is the lowest level and is well established, with a 
notation and set of conventions which have become standard- 
ized over many years of electrical engineering practice. 
During the relatively few years that digital electronics has 
been in existence the switching circuit level has also be- 
come well established, allowing designers to avoid much of 
the detail necessary in describing their systems at the cir- 
eumit level. Thus digital circuits are desiqned with gates 
and delays rather than transistors, diodesr and other com- 
ponents of the circuit level. At the other end of the 
scaler the PMS level (although the specific term was coined 
by Bell and Newell) has also been in use for Some time, 
Since this 1s the level used to describe the aqrossS provoer= 
ties of computer systems. The programming level has also 
hecome well develonved, since most digital systems have been 


the kind which require a program in order to perform useful 
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functions. The RT levels which is the one that seems’ most 
natural for conveying the structure of digital systems ana 
mterfacing between the circuit levels and the programming 
levely has been recognized as a level since the 1950's but 
has only recently been the subject of serious efforts aimed 
at formalization (6). 

During the brief history of the computer industry com- 
puters have evolved from huge pieces of hardware with very 
limited capabilities (by today's standards) to very compact 
units with very broads powerful capabilities. For all of 
this changer though, the architectures of computer systems 
still closely adhere to the concepts originally provosed by 
von Neumann (7-7 che4]). Even the development of minicomout= 
ers and microcomputers has not changed this facts, since most 
of the same features which were successful on larger comput-> 
ers have been carried over into these smaller systems. In 
factr the increased competition in the computer tndustry 
Pen has been causea by the acceptance of these new types 
of computers will probably have the effect of "weeding out" 
features which are not well conceived or introduced merely 
for uniqueness and of more or less’ standardizing features 
which prove useful across a wide range of applications. 

No attemot will be made here to describe all of the 
variations ain architecture which have evolved over the 
yearS, since a comprehenSive survey has been presented by 
Bell and Newell (7]. Suffice it to say that, while there 


are many differences among the various types of systems at 
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the switching circuit level, there are many similarities at 
the RT level. The features which distinguish one system 
from another at this level can be qrouped according to a few 


system characteristics. 


A. BASIC CHARACTERISTICS 

The two main PMS Jevel building blocks in a conventional 
System are the central processing unit (CPU) and the memory. 
In most systems the majority of the instructions are devoted 
to transferring data between these two units. In order to 
represent these ideas at the RI level Barbacci [6) refers to 
the basic components as “operators” and "carriers." 

Ooerators are entities that produce information by 
transformation of bit patterns to which meaning has heen 
assiqned. These bit patterns reside in carriersr which 
are the entities used in Storing and transmitting the 
information to and from the operators. ofr D+.) 57) 
The operators can be seen to represent the functions per- 
formed by the CPU in the classical digital system, and the 
carriers are hardware memory elements with various degrees 
of latency. Wires and busses can be considered short term 
memories, while reaisters and core memories carry informa- 
tion for longer intervals of time. 

The basic characteristics of a digital system can thus 
be Peeeribed by defining the various carriers and operators 
of which it 18 conStructed. Barbacci considers the register 
to be the basic unit in defining carrierss, and its descrip- 
tors are its name,y dimensions, and size of alphabet (typi- 


cally er aS In binary systems). All types of memory in a 


System can be constructed from registers by forming 
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SubregistersS,, compound registers,s and Rreaiculay An example of 
Subregisters I1n a tyoical SyStem 1S the Dartition of the 
instruction register into an omeration code field and one or 
more operand fields. The Intel 8080 microprocessor provides 
examples of compound registers; e.g. the H and L registers 
are considered aS separate registers 1n several instruc 
tions, but when concatenated they form the address register. 
The primary memory of a typical computer can be thought of 
as an array of registers. 

The two most primitive kinds of operators tn a digital 
system are the oneS uSually represented in a highlevel 
lanquage: logical (negater inclusive ors exclusive ors and, 
equivalence) and arithmetic (Caddition, subtraction, mutiplio- 
Cations division). Other operators needed in describing the 
System include vector operators for manipulating registers 
(shift, rotate), transfers, concatenation, and special 
operators (countingr exchangingr etc.). 

It 31S necessary but not sufficient for a compiler to 
have information about the operators and carriers of a come 
puter system. Since the primary purpose i the compiler 1s 
to generate control code for the computer, Information 
describing the instruction set is alSo required. In essence 
the compiler performs a mappina from intermediate language 
code to machine code, and it 18 necessary to provide suffi- 
ciently detailed information to carry out this mapping. The 
level of detail will be much greater if the intermediate 
Vanquage Vomeombestramstlated into microcode than tf 1t 18 to 
be translated into a conventional machine lanquage. The bit 
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patterns of all of the machine instructions are required in 
order to oroduce the actual machine coder and the mnemonics 
of the instructions (in an assembly language type of format) 
may be required in order to produce a version of the machine 
code which can easily be read by the programmers who will be 
trying to debug the programs produced. Special types of 
instructions (subroutine jumps and returns, interruot pro- 
ducing and handlingr tinout/output) must be accounted forys 
and any side effects of instructions (such as the setting of 
conditicn codes) must be described. Methods of addressing 
will have an effect on the code produced and will also have 
to be «described. For some machines it 1S necessary to 
transfer operands from main memory to registers in order to 
operate on them, while other machines have instructions 
which operate on operands directly 1n =main memory. Many 
machines have both types of instructions. Indirect address~ 
ingr indexingr and stack manipulation are important features 
which also must be described. 

The amount of detail provided about the instruction. set 
and the physical characteristics of the machine has a direct 
bearing on the capability of the compiler to produce "good" 
machine code. lf sufficient information iS available 
machine=dependent optimizations can be performed on the code 


as it is being generatedsr as discussed in Section VII.A.1. 


Oe. MICROPROGRAMMING AND MODULARITY 
Two basic classes of systems can be distinguished, the 


first being the conventional or classical type, 
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Characterized by a fixed or hardwired instruction set. 
Microproarammabdle systemS, 1n which the instruction set Cin 
the usual sense of the term) is able to be changed by altere- 
ing a memory, form the second class. Included in the latter 
class are modular systems, which in addition to having a 
variaole instruction set have a variable machine organiza~ 
EO Mie Botn classes of systems require the basic types of 
information discussed above to be transmitted to the com- 
piler. The additional types of information required by the 
compiler for microprogrammable systems are discussea below. 

Microprogqrammable systems have been growing rapidly in 
use in the last few years, but for all of the special atten- 
tion which has been devoted to its microprogqramming is not 
significantly different from "regular" proaqramming. Reigel 
and Lawson have defined microgramming as ".e. a technique 
for implementing the control function of a digital computing 
system as sequences of control sionals that are organized on 
a word basis and stored in a memorye” (48, pec) There is 
nothing in this definition which does not apply equally well 
to a non=microorogrammed computer. Eckhouse has noted that, 
with respect to microprogrammable hardware, "... all of the 
machines can be classified as classicals, von Neumann in 
nature with only minor perturbations." [18,7 p.1/7e) 

What microorogramming has done 1s allow increased flexi- 
mb ity in digital system design by providing the desiqner 
with qreater access to the hardware. IBM was the first com- 
Pany to successfully apply microgramming when it produced 

" 


the S/360 family of computers. The designers were able "... 
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to achieve ae range of compatible processors offering the 
Same larae machine instruction set at many different levels 
of performance." (8, p.3) It iS interesting to note thats in 
a sensery the common machine code of this series could be 
considered a machinewindependent programming language. 
Pernaps the attraction of microprogramming can best be 
appreciated by considering the distinction which Barbacci 
makes between architecture and machine organization. He 
considers the architecture to be the behavioral description 
of a systems 1-@er what the programmer perceives the system 
to be. On the other hands the machine organization iS "ee. 
the ovarticular combination of reqistersr busseSr combina= 
tional networks, and control ..." in a system. [6r 9.144) 
The architecture influences the machine oraanization by 
impoSing a set of requirements (a particular instruction 
set) and the oraanizations mainly for technological rea- 
sonsr influences the architecture of the machine. The 
result is usually that a given computer architecture can 
be implemented on a set of machine organizationSr and a 
given organization accepts several architectures. 
for, p.144) 
Thus 1N a conventional computer system it 1S mnmecesSary to 
describe only the architecture of the machine. The instruc> 
tion set serves as a level of abstraction separating the 
programmer (or compiler) from the machine organization. In 
a microorogrammed system another instruction Set may be 
defined in order to preserve this abstraction, but if the 
programmer 1S to work tn a high=level lanquage it may be 
possible (but not necessarily desirable) to skip this step 


by allowing the compiler to interface directly with the 


machine organization. 
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The major hurdle in microprogramming is the introduction 
of timing considerations to the list of information ren 
quired. In describing the basic information required by a 
compilers no mention was made in Section VI.A of the timing 
of instructions. The reason for this is that conventional 
systems usually operate in a sequential fashions with the 
execution of one instruction not beginning until the previ- 
OuS instruction has been executed. Even though many events 
may be occurring in parallelr this is hidaen by the instruc= 
tion set. Une of the values of microprogramming 1S that it 
allows the programmer to specify the concurrency of certain 
events. Unfortunately this additional flexibility 1s ob- 
tained by increasing the amount of detail with which the 
programmer must cope. This is why instruction sets similar 
to those of conventional computers are usually defined for 
microprogrammable systems. For exampler the Intel 4000 
series of microprocessor chips has been advertised as a 
microprogrammable microprocessors however, the series has 
not yet been exploited to its fullest potential bdecause 
Intel is still in the process of defining a hiqgher=level 
instruction set comparable to the typical machine’ Ilanauage. 
More of the conSiderations involved in working with con- 
Current systems are presented below in Section VI.C. 

Another trend which iS occurring in the digital elec= 
tronics field is the development. of modular systems 
{16,31,756). Tne reasons for development of such systems are 


very similar to the reasons for some. of the software 
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engineering concepts (see Section 1.8). In facts modularity 


(of programs) is one of the principles of software engineer= 


Na. In addition to the variable architecture characteris-= 


tic of other microorogrammable systems, modular systems have 


variable machine organizations. tTthus the task of program- 


ming these systems 1S even more difficult. 


If develooment of different types of components can be 


reduced, and if standardization of modules, test 


pro 


cedures, and loaistic support can be achieved, the life= 


cycle cost of systems can be aqreatliy reduced. 


One 


approach to implementation of this idea 18 to identify a 


level of modularity for components which can have 


wide 


apolication in many types of systems. This allows the 


development cost of the modules to be spread over 


many 


UNItS, while reducing the quantity of components and the 


logistics costs. (567 p,.53) 
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Fiqure 14. Example of a three=bus 
modular system using QED modules 
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One of many possible configurations for a modular system 
is Shown in Figure 14 (56, p.19). j%qThe control module in 
this type of system would probably consist of a read-only 
memory programmed to initiate all actions required by the 
system performance specifications. This type of system 
would be very similar to a micronprogrammable computer in its 
operation and control code structure. Thus the main problem 
in programming such a system will be to take maximum advan= 
tage of parallelism. The designer will also have the prob- 
lem of selecting the most appropriate types and numbers of 
modules to use and the problem of choosing the most effi- 
cient organization. (ieee.r, the number of busses and the con- 
nections of modules to busses). 

An alternative type of modular system would spread the 
control function among all of the modules rather than con- 
solidating it into a single module. Such a system would not 
be program controlled but would accomplish its t/esks by have- 
ina the various modules: communicate with one another by 
means of "“reaay"” and "acknowledge" siqnals. Because such 
modules would not be as flexible as the type shown in Figure 


14, they probably will not be as widely used. 


. PARALLELIS™ 

The raoid growth of the computer industry has been 
spurred by the eversincreasina speed of computer hardware 
brought about by continuing advances in the electronic com- 
ponent Industries. mates tubes gave way to transistors 1n 


the late 1950's and early 1960's, and the latter were 
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supplanted by integrated circuits in the pace ou oun These 
small-scale integrated (SSI) circuits were soon antiquated 
by medium-scale integration (MSI) technology, and direct 
gate-level and reaisterv-level design (without considering 
the circuitctlevel) became possible. Today large-scale ino- 
tegrated (LS1]1) circuitry is available in large quantities, 
and whole subsystems can be manufactured on one small chip 
of silicon. While these tremendous increases in circutt 
density have played an important part in increasing the 
speed of digital systems, they have been accompanied by 
advances in the state~ofethe~art in semiconductor manufac- 
ture which have allowed much faster Switching times to be 
achieved. 

Unfortunatelyr there are physical limits to the 
Processes which have brought about these vast changess and 
the semiconductor industry will soon be nearing them. AS a 
resultry increases in computer circuit speed will be coming 
at a much slower rate than in the past (Cunless some new 
technology is discovered which does not depend on the motion 
and storage of electrons). Thus any furtner major advances 
in computer speed will have to rely on increased use of 
advanced machine organization techniques which take advan- 
tage of features such as parallelism and pipelining. Paral-~ 
lelism refers to the concurrent performance of multiple 
tasks in a system, where a task is "... a self-contained 
portion of a computation for some other computer operation) 


that once initiated can be carried out to its completion 
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without need for additional inputs." (46, p.986) Pipelining 
is accomplished by dividing a task into many independent 
Subtasks such that a new process can begin the task as soon 
as the previous one has completed the first subtask. I[n 
this way many orocesses can be performing the same task, 
each being in a different stage of comoletion. 

Another factor which has resulted in the increased use 
of parallelism in digital systems is the growing emphasis on 
modularity and microprogramming discussed in Section VJI.B. 
Modularity in hardware may be looked at from several 
viewpoints, from small modules such as registers.and busses 
considered in microprogramming to large functional modules 
as discussed by Tinklepaugh and Eddington (56). This wide 
diversity means that there are several levels of parallelism 
which must be consideredr each with its own unique problems 
and methods of solution (46). 

The fact that parallelism is a significant consideration 
in the design of a digital system is highlighted by the fact 
that at least one entire book has been devoted to the  sub- 
ject {39}. Several high-level language compilers have been 
developeo or proposed for use with the new generation of 
array processors, which rely heavily on the use of parallel- 
ism at the instruction and arithmetic exoression levels 
[59). Ramamoorthy, Park, and Lee (46) present a good over= 
view of some of the factors involved in working with paral>- 
lelism and present several algorithms for taking advantage 


of it at the arithmetic expression and subexoression levels. 
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There are two basic ways 1N which Darallelism may be 
handled in a high=level languagerstexolicitly or implicitly. 
In the explicit approach there are special instructions 
included in the language (e.gqer, FORK and JOIN) by which the 
programmer may indicate sections of code which may be exeo- 
cuted in parallel. 

The explicit approach iS advantageous for the recognition 
and representation of parallelism between blocks On 
Instructions or between instructionsr since the analysis 
of parallelism between tasks at these levels is simole. 
However, the explicit approach 1s not advantageous for 
recognizing and representing parallelism at arithmetic 
operation (sSubexpression) or micro=step level, because it 
is tedious and mistake prone. [46, 0.986) 
The implicit approach places the burden on the compiler by 
incorporating two new steps in the compilation process. The 
first steo involves the recognition of parallel processable 
tasks, and the second involves representation of the infore- 
mation obtained in the first step and allocation of 
resources in such a manner that maximum advantage 1S taken 
of the parallelism. "This anproach involves considerable 
overhead to recognize 5S SOeT EN tasks in a program although 
it relieves programmers of additional duties." [46 p.986) 

Thus, as is usually the case in desian work, there are 
tradeoffs involved in determining whether to use the explic- 
eat or the renin approach to. parallelism. At the current 
State-of-the-art in compiler design it 1s probably desirable 
to use some combination of the two. The explicit approach 
can be used for blocks of instructions (fe.ger Subroutines), 


and tne implicit aoproach can be used at the arithmetic 


expression level to reduce the number of programming errors 
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which would result from using the explicit eee at this 
level. 

In either approach the compiler can be given the job. of 
allocating the resources for execution of the program. The 
major problem in this area involves the proper synchroniza= 
tion of the various pieces of hardware. Again there appear 
to be two possible methods for approaching this’ problem. 
One way would require that the description of each module 
contain information about the maximum time required for the 
module to perform a given function. Then once the compiler 
had assiqned a task to a particular module it would have to 
allow the snecified amount of time before it could issue an 
instruction requiring the results of that module to be 
available. This approach has the disadvantage that it would 
not allow the hardware to operate at maximum speedr- since 
many functional modules (e.g.r multipliers) have a wide 
variation in speed depending on the input data. The other 
approach is the one used in modern overating systems for 
sophisticated computers. In essence this would involve set>- 
ting up aesmall operating system which would perform the 
resource allocation at execution time rather than compile 
time. Synchronization would be accomplished by sending con- 
trol siaqnals to the various modules and receiving signals 
from the modules to indicate task completion. Obviously 
this method involves a fairly significant amount of overhead 
in the form of additional memory required to hold the 


operating system. Thus the programmer would have another 
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tradeoff to make in determining which nethod would be most 
appropriate for his application. 

As in the other sections of this chapters many ideas 
have been presented in this section. No specific recommen- 
dations have been made as to which of them may be applicable 
to a compiler for usersedefinable architectures, Since the 
determination of such recommendations will require a consid= 
erable amount of additional research and experimentation. 
The intent here has been to exhivit a (not necessarily all- 
inclusive) list of some of the things which must be con 


sidered in implementina "pass 2" of such a compiler. 
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Vid ec Une IEeER UPTIME ZAT ION 


Optimization is a frequently pursued goal in the desian 
of engineering systems, whether they be hardware systems or 
software systems. The mathematical solution of an optimiza-~ 
tion problem requires finding the minimum of a cost function 
(or maximum of a reward function) while satisfying a set of 
constraints. Unfortunately the equations involved are often 
nonlinear, making a closed-form solution impossible. 
Attempts at solution by enumerating all the possibilities 
are usually not practical for nontrivial problemss because 
the enumeration expands in a combinatorial manner. CIn 
optimal control theory this problem has sometimes been re~ 
ferred to as the “curse of dimensionality.") Thusr though a 
large body of theory has been developed to deal with optimi- 
Zation problems, often the only practical solution to a 
problem involves’ the use otf ad hoc methods. Such has been 
the case to a large extent in dealina with the problem of 
code optimization. 

Another significant barrier to the application of good 
optimization techniques is the general difficulty of speci-~ 
fying what constitutes an optimal solution to a given design 
problem. In fact it has been noted by Aho and Ullman, with 
respect to the code generated by a compiler, 

mm. that there is no SOC RIIC way to find the shortest 


or fastestcmrunning program equivalent to a aiven program. 
eee Thus the term optimization is a complete misnomer~="in 
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practice we must be content with code improvement. Vario 
OouS code improvement techniques can be employed at various 
phases of the compilation process. (3, pa U- 7g 
rt is the ourpose of this chapter to discuss the motivation 
for research in the area of compiler optimization and to 


examine some of the formal techniques which may prove useful 


in implementing compilers for firmware design languanes. 


A. MOTIVATION 

As far back as the early 1950'sr when the FORTRAN I come- 
piler wasS being designed, it was recognized that convenience 
alone was not enough to persuade programmers to use highe- 
level ionawaces P52) < Unless the compiler could produce 
machine coge which was comparable in efficiency to hand-~= 
coded programs there would be a great deal of resistance to 
the use of high-level languages. In the intervening” years 
computer architectures and instruction sets have increased 
a complexityr making it even more difficult for a compiler 
to match a good assembly lanquage programmer. 

Three computer Sau ane trends which have develooed over 
the years are the increase in speed, the increase in main 
memory sizer and the increase in size and power of the in 
struction set. These trends have had the effect of reducing 
the need for optimization in compilersr since for many = ap-~ 
plications the hardware efficiency more than offset the 
compiler-qenerated code inefficiency. In recent years there 
has been yet another trend=-the acceptance of minicomputers, 
and now microcomouterss a components in the desian of 


larger systems. In such applications the cycle 1s beginning 
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to repeat, since these smaller computers typically have slow 
execution times, a smail amount of memorys anda relatively 
limited .number of instructions. Thus the programs” written 
for these devices must be as efficient as possible in order 
to minimize the amount of hardware used. Even in sophistic 
cated microprogrammable systems, though, the amount of 
hardware used may be critical in determining the profitabil= 
ity of a given gesign. AS a consequence, code optimization 
is becoming increasingly Important Va wWorder, to allow 
firmware designers to take advantage of all the benefits of 
high-level language programming. 

An example of the kinds of inefficiencies involved is 
Shown 1N Figures 15-17. Figure 15 shows a PL/M program’ for 
performing a simple bubble sortsr while Figure 16 shows a 
hand=coded Intel 8080 assembly language version of the same 
program pas). Note that neither of these programs would 
actually be run by itself but would probably be a procedure 
in a larger program (in which ARRAY and N would he given 
values). The purpose here is to examine the code generated 
Hoeeecne sorting algorithm without getting involved in the 
various issues of Subroutine linkage. 

Figure 17 shows the output (reformatted by the author 
for ease of comparison) of the Intel 8080 PL/M compiler, 
version 1.0. Not counting storage space for the variables, 
the handaw-coded version requires 40 bytes of storage, and the 
compiler version requires 116 bytes-=7a relative inefficiency 


Of 190 percent. A similar but somewhat larger version. of 
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1. DECLARE ARRAY(256) BYTE, 

as (NeIe-Tl1e-TeesSwITCHED) BYTE? 
Be SING ste 0) ae 

4. DO WHILE SWITCHED, 

Die SWITEHED = 07 

oye DO I = 1TON = i, 

(ee Ti = ARRAYCI); Te = ARRAYCI + 1); 
oe IF Ti > Te THEN 

9. DO; 
1:0), ARRAY(CI+1) = Til; 
Li. ARRAY(I) = Te; 
ee SWITCHED = 1; 
15. END; 
i4. END; 
are END; 
pose COF 


Figure 15. PL/M bubble sort program 


| MVI Del 
ee. Lis MOV A,D 
Si ADI 0 

4. RTE 2 

Se MV] D,90 
6. MVI HeN.n 
Ls MV] LeNeL 
On MOV By M 
9. MV] H, ARRAY .H 
10% MVI Lr,ARRAY.L 
ie LSs OCR B 
le. JZ Ll 
Lo. MOV A,M 
14, INR e 

ove CMP M 

ibios 5 ie L3 
7. MOV C,™M 
VS. MOV My, A 
19. DCR L 
ee MOV “M,C 
Fase) A INR L 
Ces MV I Dri 
Ca. JMP L3 


tee es adieu 


Fiqure 16. Hanoa=coded 8080 assembly language 
version of bubble sort program (after Pooper [435] ) 


an LX] SP,0O0F 4H Sa DCR L 

cae LX] H, SWITCHED SO. SUB M 

iS, MV I Merl Sis JNC Ls 
ieee) s LX] Hr, SWITCHED Cie DCR L 

5. MOV A,™ 39. MOV C,M 
ie RRC 40. INR C 

i JNC L4 a1. MOV Loe 
ome MV I M, 0 Wo. MV I H, 0 
9. Mv J LrI.t 43. LXI D, ARRAY 
HO. MV I Mel Ga, DAD D 
Mmieeetc: LXI Hy N Si XCHG 

lee MOV CeM 46. Lx I H, Tl 
eS. DCR C G7. MOV CaM 
14. MUV A,C 48. MOV A,C 
ee INR e 49, STAX D 
oe SUB M S50. er te) J 
ry. JC Li 51: MV] H, 0 
ote LHLD i Se. LX] DOD, ARRAY 
ro. AVI H, 0 Sie DAD D 
eos. LX] D, ARRAY 54. XCHG 
els. DAD D 55% LX] H,rTe 
pe. MOV A,™ Sloe MOV C,M 
ES. EAI H, Tl 57. MOV A,C 
pl. MOV Mr A 56. STAX D 
2 DCR L oo. INR L 
i om MOV C,™M 60; MV I M,l 
el. INR G Ol. Ea MV I ey Tek 
oe MOV rt 62e-6 MOV C,M 
Bl. MV I H, 0 63. INR C 
iO. ex D, ARRAY 64, MOV M,C 
oy as DAD D 65. JNZ leg 
SCs MOV Ay™M 66. oir Le | 
53. xT Hr Te 67. L443: EI 
34, MOV M,A 66. HLT 


Figure 17. Reformatted PL/M compiler output 
for bubble sort program of Figure 15 


this program, cited by Falk (19), was hand-coded for the 
Intel 8008, and required 347 bytes of code. The initial 
version of the 8008 PL/M compoviler generated 495 bytes of 
code for this larger program="a relative inefficiency of 47 
percent. A later version of the 8008 PL/M compiler (con- 
taining improved optimization techniques) generated 388 
bytes of coder, yielding da le percent relative inefficiency 
(34). 

This tends to confirm the fact thatr in most applica- 
tions, compiler-produced code compares more favorably with 
assembly code as the size of the program increases. Al1So 
the current PL/M compilers use relatively unsophisticated 
optimization techniques, and further improvements could be 
obtained with relatively little additional effort. 

Comparison of Figures 16 and 17 shows that the bubble 
sort program brings out two of the most severe problems’ in 
compiler code generation-=the register allocation problem 
and the subscript calculation problem. Less significant, 
but also evidentr are the differences in the methods of 
branching for the loops and the four extra bytes of code 
generated by the compiler for all orograms (to set the stack 
pointer at the beginning and enable interrupts at the end). 

The assembly language version takes advantage of the 
fact that there are enough index registers available on the 
EPoUs to hold sll temporary Wariables needed in the sort 
routine. This saves at least three bytes of code (to load 


the address into the HL register) each time one of these 
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variables is referenced (unless the address is already in HL 
from a previous reference). 

The greatest Saving in the program of Figure 16 results 
from the use of the HL register aS a pointer into the array 
being sorted. The programmer realized that the elements) of 
the array being referenced at any time were always adjacent 
to one anothers and he stepped through the comparisons”) and 
Swaps by appropriately incrementing and decrementing the 
address register. The current compiler 1S not capable of 
making this optimization and so recomputes subscripts for 
each variabdle reference. 

An attempt was made to rewrite the PL/M program to more 
closely match the structure of the assembly language version 
(see Figure 18). In the new program the iterative loop was 
replaced with a WHILE loops, and the swapping oprocess was 
modified so that it would use only one temporary variable. 
Unfortunately the Savings produced by these changes were 
offset by the computation of one additional subscripts, and 
the new orogram generated as much code as the old. 

As mentioned in Chapter IIs one of the advantages of 
programming in a high=level language is the ease with which 
changes can be made. Figure 19 shows the minor PL/M program 
changes (to the declaration statements) which would be re- 
quired if the array to be sorted contained more than 256 
values and if the values were double=byte (address) rather 
than single-byte. Two other changes have been indicated in 


order to make the program technically correct. Of course 
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DECLARE ARRAY( 256) BYTE, 
(SWITCHED-N,I-TEMP) BYTE; 
SWITCHED = 1, 
DO Whee Swill Cee, 
SWITCHED = 0; 
I = N; 
DO Whihb bes (lec == 1); 
IF ARRAY(I) > ARRAYCI+1) THEN 
DQ; 
TEMP = ARRAY(I); 


— 
COCOONS UY SWAY = 


whe AKRAYCI) = ARRAYCI+1); 
lc. ARRAYCI+1) = TEMP; 

13. SWITCHED = 1; 

14, END; 

15. END; 

ee END; 

li EOE 


Figure 18. PL/M program revised to match 
the control structures of the assembly language version 


GA DECLARE ARRAY (256) ADBWRESS, 

Bae (N,I,TEMP) ADDRESS, 

ore Sw VCHED BYTE; 

fie SWITCHED = 1; 

53 DOS WILE SWIERGHED; 

Oi SAITCHED = 0; 

is I =Ne- ll; 

8. DOSWHEDE Cl 3] T-<"1) + 1; 
9. IF ARRAY(I) > ARRAYC(I+1) THEN 
iO. DO; 

ri’. TEMP = ARRAYCI1); 

hic: ARRAYC(I) = ARRAYCI +1); 
| Oe ARRAYCI+1) = TEMP; 

La SWITCHEO = 17 

Jigen END; 

16. END; 

ss END; 

ele EOF 


Figure 19. Modified PL/M proaram 


tne changes caused much more code to be generated (197 bytes 
as opposed to 116) in order to handle the double~pvoyte arith= 
metic and data transfer operations. The interesting point 
here is that an assembly language versions, if one haa heen 
written for this new problem, would certainly be much longer 
than 40 bytes since there would be insufficient registers 
available to hold all of the temporary values. Also the 
compiled version would have a much lower relative ineffi- 
ciency in relation to such a hand=coded version of the new 
program. The amount of effort required to chanae the pro- 
gram would obviously have been many times greater than was 


the caSe for the PL/M version. 


Pee rECHNIQUES 

In his excellent compiler optimization survey Schneck 
(S2] has classified optimization techniques into three func- 
tional categories based upon the amount of knowledge they 
require about the object machine. He calls the three ca- 
tegories machine=-dependent, architecture=dependent, and 
architecture-independent. Some of the more important tech- 
niques in each category are highliqnted below in order to 
show that many of the inefficiencies usually associated with 
compiler=generated code can be eliminated if careful atten- 
tion is paid to optimization. 

1. MachineDenendent 

Machine=dependent optimizations are also classified 

as local] onmtimizations since they are applied to short spans 


of code during the code generation process rather than prior 
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to code generation as indicated in Fiqure 4. Thus these 
techniques require a detailed knowledge of the instruction 
set of the odject machine. For examples, if the operation to 
be performed is an addition and one of the ooerands 1S known 
at compile time to have a value of oner the code generated 
would oe an increment instruction if one were available. 

The majority of the optimizations in pass e@ of the 
Intel PL/M compilers fall into this category. The results 
of some of the more subtle ones can be seen in Figure 1/7. 
It should be noted that the MVI instruction has deen used 
whenever possible to Seniane data transfers. This instruc 
tion requires two bytes of memory rather than the three 
required by the LXI instructions, which could also have’ been 
used for this puronose. AISO noteworthy is the use of the 
increment and decrement instructions. 

As an indication that these kinds of optimizations 
‘may not be aS easy to apply as it might at first appear, 
consider Figure 20. This figure shows the PDP=11 machine 
code [15] generated for the two functionally equivalent sets 
of C language statements discussed in Section III.8. It can 
be seen thatr while the compiler has used increment and 
decrement instructions in both casesr the code in Figure 
C0(b) is less efficient than the otherys even though it has 
been passed through the optimizer associated with the C com- 
piler. (In fairnessry it should be noted that the optimizer 
1s claimed to be only experimental.) This points up the fact 


that machine=dependent optimizations tend to he applied in 


+44 = key 


} jor o- ks 
INC j 
mov jr, rO 
sub k, r0 
mov rO-ry 
mov j,rO 
sub k, r0 
dec j 
mov rderi 
(a) 
+ = (j = 3} + 1) = kz 
oh Kean = 3 = le 


mov jr r0 
INC r0 

mov r0,j 
sub k, r0 
mov rOey 
MOV j,rO 
Sub: k, r0 
Mov rO¢1 
mov jr, rO 
dec rQ 

mov rOrj 

(ob) 


Figure e0. PODPell assembly code for two 
equivalent sets of C language statements 
(a) using increment/decrement feature, 
(bob) using addition and subtraction 
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an ad hoc manners that 1Sr by testing a series of conditions 
which would indicate special cases in the code being aqen-e- 
erated. 

There is littler if anys mathematical rigor associo 
ated with these methodSr and they thus are very similar to 
the Pind: of optimizations which an assembly language proe- 
Grammer would make. This is the major reason for the cross- 
over in relative efficiency between assembly language and 
high-level language programs as program size increases (see 
Section II.4). For the high-level language the special 
cases must be foreseen by the compiler writer. Since he 
probably will overlook some, the compiler will generate some 
code which is obviously inefficientr as in Figure 20(b). 
Neverthelessr those optimizations which can be applied to 
cases foreseen by the compiler designer will be applied con- 
sistently by the compiler every time the aporopriate condic- 
tions are satisfied. The assembly language programmerr on 
the other hands, will easily spot the kinds of inefficiencies 
shown in the example Cand in the example of Figures 15-i7), 
but he may not be consistent in applying optimizations. and 
may not recognize others because of the complexity of the 
program. The inefficiencies contributed by these two facc- 
tors tend to duild up rapidly as the assembly language pro- 
gram increases 1n Size. 

ee. Architecture-Dependent 
Architecture-dependent optimizations are alobal in 


nature and depend on the architecture of the object machine 


but not the instruction Set. Fxamples of architectural 
features which are considered are the number of registers, 
the number of processing elementSr and the degree of pipe-~ 
len ing. As can be seen, these types of optimizations aqen= 
erally involve resource allocation and thus would be very 
important IN compiling for microorogrammable and modular 
Systems. The reason these are considered to be global op- 
timizations is that the resource requirements of diverse 
segments of a erogram must be considered when making the 
allocations. 

The important register-allocation problem fits into 
this category, since its solution depends on the numbers and 
types of registers available in the architcture. The pare 
ticular machine instructions are not important in this case. 
It should be recalled that poor register allocation waS one 
of the major causes of inefficiency in the code of Fiqure 
vee Alaorithmic solutions have’ been found £0 the 
registerv-allocation problem for simple straiaht=line (Cnon- 
looping) programs [(52e)+, but a general solution is either not 
possible or not practical. The former is usually the case 
iN programs which contain Conditional brancheS-s since the 
flow of execution of the program is almost always unknown at 
compile timer and this information is needed for an optimal 
solution. The latter is usually true for long programs, 
even if they contain no loops, since an optimal solution 
would require an analysis of the entire program and an 


enumeration of all possible combinations Ont register 





assiqnments. Freiburghouse {20) has ers 1 oresented a 
metnod for solving the registersrallocation problem which 
takes advantage of information which can be accumulated dure 
ing the normal course of compilation and which appears to 
Qive results closer to the optimum than other proposed solu- 
tions. 

As discussed jin Section VI.Cr parallelism is an 
important er in firmware systemS, and the generation of 
code to take maximum advantage of this parallelism is anoth- 
er architecture-denenaent optimization problem. An impore- 
tant use of parallelism in improving execution of a program 
lies in the area of reducing the time required for iterative 
segments of code. For example, the PL/M code of Figure 21 
could be translated into more timerefficient code if several 
arithmetic units were available than if only one were availo= 


able. 


DO I = 1 10 20; 

hea Date lt ly). * ec, 
CCI) = CCI) + A; 

D(I) = OCI) = A; 

END; 


Figure 21. Iterative code for which 
parallel processing would be useful 


As is usually the case in optimization problems, 
there are tradeoffs which must be made when dealing with 


parallelism. - The two methods shown in Figure ee for 
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/\ C CC €CC(CA*B)*C)*D) *E) *F)*G)*H 


(a) 


i ON (CA*B)*(C*D0))* (CC E*F)*(G*H) ) 


Figure ee. Tree structure for serial and 
parallel) computation of an expression. (a) Tree yielding 
minimum number of registers, (bo) Tree yielding 
maximum inherent parallelism (52, p.2) 


calculating an expression can be used to illustrate this 
point. If code were being generated for a machine with only 
one register the scheme in Figure e22ela) would be better than 
that of Figure 22(o)r while the reverse would be true for a 
machine with four multipliers and four registers. For a 
machine with fewer than four multipliersr though, it 1S not 
obvious which method would be better. In Such situations an 
analysis must be made of the various types of instructions 
involved. Une way to do this would be to assign weights to 
the instructions based upon their execution times (e.G.r a 
multiplication instruction would have a greater weight than 
an addition instruction) and then generate the code which 
achieved the minimum total weight for the desired 
computation. 
3. Architecture-Independent 

The final and most general category consists of the 
architecture-independent optimizations. Since these do not 
depend on the architecture or the instruction set of the 
object machiner they are obviously applicable to compiling 
for user-definable architectures. These kinds of optimiza- 
tions can be applied to the intermediate language code 
without considering the hardware features available. As in 
the case of architecture-dependent optimizations, these op- 
timizations are global in nature. The most commonly aoplied 
techniques in this class are common subexpression el]imina= 
tions, dead variable eliminations, code motions, and constant 


propagation. Since these techniques are widely discussed in 


the literature (seer e-.Ger (4) for a good survey and (13) 
for an application) only a brief description 1s presented 
here. 

Common subexpression elimination is the most widely 
emoloyed technique [Se]. Basicly it iS concerned with 
avoiding redundant computations, such as for the second 
occurrence of “B*C" in Figure e3l(a). Dead variables’ are 
those whichr beyond a given statements, never again appear on 
the right=hand side of an assignment or are never = aqain 
referenced. In the first case the variable need not be kept 
in a high-speed registerr and in the second case it need not 
any longer be assigned any memory at all. Code motion 
refers to the movement of sections of code so as to reduce 
the execution time of a program. For example, the section 
of code shown in Figure 23(b) would be significantly im- 
proved if the assignment to "D" were moved outside of the 
loop. Constant propagation is really a special case of code 
motions since calculations involving only known constants 
are moved from the execution phase of a program to the com-= 
pilation phase. The computations of "C" and "D" in Figure 
23(c) orovide examples of propagated constants. 

Architecture=independent optimization techniques 
rely heavily on theoretical work and are amenable to the 
application of sophisticated algorithms. They usually in- 
volve a global flow analysis of the intermediate form of the 
program and may rely on graph theory or matrix analysis. 
Unfortunately most of these techniques are very complicated 
and require large amounts of memory and time. 
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D=xX * ¥ / Z + 50; 
BCI) = C(I) «* D; 
END; 
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Figure 23. Architecturerindependent 
optimization candidates. (a) Common subexpression, 
(bye toce mot vom (Cc) Comstamt propagation 





Since a useful program usually contains many 
branches and loops which make it impossible to know at com= 
Dilation time how often (if ever) many sections of code wil] 
be executed, frequency analysis 1S Sometimes employed in the 
optimization process. By asSianing a relative frequency or 
welght to each block of code in a program, the programmer 
allows the optimizer to perform a Monte Carlo simulation to 
determine tne "optimum" code sequence [52]. There have even 
been proposals [24] to employ an adaptive optimization pro- 
cess to perform the optimizations at run time. In such a 
scheme a large a ee the effort would be devoted to 
optimizing sections of code which are heavily useds since 
they account for most of the execution time. Such a scheme 
probably would not be practical for most real-time systems 
unless the adaptive optimization were done during the 
development process and the resulting optimizations were 


applied to the final system in a nonwadaptive mode. 


Gree ePPLICATION 

From the discussion in Sections VII.A and VII.B it can 
be seen that compiler optimization is a complex problem. A 
Good optimizing compilers in effects attempts to match wits 
with a qood assembly lanaquage programmer. In order to do 
this effectively the compiler must have a great deal of 
"artificial intelligence” built into it, and this 1S some= 
thing which, unfortunatelys is difficult to do. "Optimiza= 
tions originating in ane academic ano scientific community 


tend to be global, whiles, until recentlys manufacturers have 
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concentrated on local and machine-dependent techniques.” 
{(S2, pel) Yore efficient algorithms must be developed in 
order to allow the academic solutions to become more useful 
in practical compilers. More general and powerful tech- 
niques for handling local and machine-denendent optimiza= 
tions must also be found. For the types of systems under 
consideration here, many of the techniques discussed above 
are already practical, since comoilation costs are only a 
small part of total development cost. 

A great deal of care must be exercised in the applica- 
tion of optimization eeanasicues in code generation. Many of 
the techniques involve reordering of arithmetic operations, 
and this can lead to unexpected and often undesired results 
(e.g. from a numerical analysis point of view). Thus it 
appears that a great deal of work remains to be done in this 
area. It 1S evidents thoughe that as better techniques) are 
developed and the cost of current techniques (Cin memory and 
time) are brought lowerr high-level languages will continue 
to become more attractive. 

Until some breakthrough comes in the artificial intelli- 
gence area the most practical techniques will orobably 
require the programmer to orovide some input to the optimi-= 
zation process. He might specify that speed is most imoor- 
tant for certain sections of code and that the amount. of 
memory utilized should be minimized for other sections. He 
might also specify the probabilities of certain branches in 


the program (as has been done in some compilers Since the 


hel 


Igs0°s [52))., The computer then wil] perform the “dirty 


work" much more effectively than a human writing in assembly 


language. 


ree 


Vili tHe CONRIGURAELVON=(NOEPENDENT COMPILER 


The previous seven chapters have discussed feaunes: 
availanle in current compilers and features which appear 
feasible for future compilers. In this chapter an attempt 
1s made to tie togetner some of these ideas and discuss’ the 
possible functioning and structure of a compiler for which a 
target machine and lanquage are not necessarily specified 
prior to compilation. The level of interest in developing 
such a compiler 18 indicated by the Ceerinee amount of 
work being done on machinerindependent hiah-level micropro= 
gramming and system programming lanquages Pes nO. Ar S Tae 

Ramamoorthy and Tsuchiya {47] have demonstrated a 
language which appears to have many of the desired features 
and which can produce control code for a complex micropro- 
Qrammable machine. Their SIMPL (Single Identity Micropro- 
Oramming Language) is intended to be machinetindeopendents 
however, it does not appear that they have yet addressed the 
problem of specifying the machine organization to the com- 
Piler in a flexible manner. 

Wilcox f61) has looked at the latter problem but has 
based his work on tne concept of a machinerindependent = as- 
semoler. This assembler 18 to be used for generating con- 
trol code for digital systems built with QED functional 
modules [56). The nature of this problem is very similar to 


that considered by Ramamoorthy and Tsuchiyar and there does 


eS 


not seem to be any practical reason for not extending 


Wilcox's concept to a machine~independent compiler. 


AS THE IDEAL COMPILER 

The truly tdeal compiler would be one which would accept 
an alaorithm from the programmer in a universal programming 
language, select the most appropriate hardware for the job, 
and produce the code for controlling the hardware. Obvious- 
ly the compiler would require more input than just a state- 
ment of the algorithm. It would need to have information on 
what hardware was available and the operational constraints 
to be oplaced on the resulting system. 

A compiler which could function as described above 1S _ a 
goal for which compiler designers can strive, but it 1S one 
which will probably require many more years to achieve. The 
reason for this is the reason that computers have not taken 
over all other engineering disciplines=-there are too many 
subtle tradeoffs to be made in designing a system. The 
relationshios vetween yee the variables involved cannot 
be quantifiedr and a great deal of experience and intuition 
is required to oroduce a good design. A large part of any 
design effort iS concerned with optimization of some Sort, 
and, as ARC use in Chapter VII, this involves the area 
which the computer scientist labels artificial intelliaqence. 

Short of the ideal, the programmer (system designer) 
will have to specify a few possible hardware configurations 
along with the Bat cation functions and constraints. The 


compiler will then make some Simple tradeoffs among the 
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various configurationsr choose the “optimal” oner, and pro- 
duce the optimal code. In a given designe for example, the 
compiler miqnt decide that a system with three multiplier 
modules would be better than one with two or four multiplier 
modules. 

It will probably be Several years before even this re- 
duced caoability compiler can be implemented. Based upon 
what appears feasible within the next few yearsr the “ideal” 
compiler would be even more’ restricted. As indicated in 
Section IJI.A this compiler would have several inputs. In 
addition to the A micaunnr the programmer would specify the 
hardware Te ee the format of the control code, and 
some simple optimization information. A conceptual block 
diagram of such a compiler is shown in Figure 24. In actual 
practice it may be difficult to divide the compiler into a 
set of neat boxes with definite flow of actions a fact which 
is suggested bv the cashed line in Figure 24, In other 
words, there will probably be a strong interaction among the 
various sections of Such a compiler. 

It will probably be especially difficult to distinguish 
the architecture-dependent optimization phase from pass e. 
These two phases relate fairly closely to the final two 
steps in a SIMPL compilation="-the concurrency and timing 
analysis step and the microoperation timing optimization 
Steo. (The first two steps are Syntactic analysis and se- 
mantic analySiSs, which parse the source program and break it 


into a series of sSubblocks.). The concurrency and timing 
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Fiaure 24, Conceptual diagram of a compiler 
for usersdefinable architectures 
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analysis step eee OXamines symbolic code in each subblock 
to detect concurrently executable microoperations and to 


*, 


determine their feasible execut.ion timing." (47, 9.796) 
Nexte the microoperation timing optimization step "... ine 
troduces complete machine dependence..eee The haragware or= 
ganization and opveratina characteristics are defined by the 


microinstruction definition that is represented internally 


uaeethe comoiler.” (47, p./797]) 


Be INwTRODUCING MACHINE DEPENDENCE 

Pronably the most difficult oroblem which will be en- 
countered in desiaqning a compiler for usersdefinable archic 
tectures will be that of introducing machine dependence. 
Compoilers for fixed architectures have machine-dependent 
information scattered through all of their phases. The 
configquration=independent compilers, on the other hands must 
have machine=dependent information localized to as few areas 
as possible and must be structured in such @ way as to make 
it as easy aS possible to change this information. It is 
because of the fact that machine dependence has to be introm 
duced at some stage in any practical compiler that the term 
"compiling for uSsersdefinabdle architectures" has been used 
in this thesis. The technically inaccurate term "machine= 
independent compiler" is often encountered and has the same 
Meaning. 

As indicated in Figure 24, information on optimization, 
machine organizations and instruction formats will be tabu- 


lated by the compiler. After suitable processing, the 
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information will be loaded into tables 1n much the same way 
tnat the information from the algorithm is loaded into the 
symbol taole. The architecture-dependent optimization phase 
and pass e will thus’ be “tablewdriven"; i.ee.r they will 
extract information from the various tables and use this 
information to make optimization and code generation deci=- 
SIONS. In the sense that they use information from the sym 
ome Cable to generate Yeontrol coder the second passes of the 
two current Intel PL/M compilers for the 8008 and the 8080 
microprocessors can be considered to be partially table- 
driven. 

Tirrell (57) has reported work involving the use of 3a 
table-driven compiler for microproaqrammina. In his com- 
piler, tables containing machine-dependent information eould 
be loaded prior to compilation or could be generated during 
compilation. One table was used for indicating the status 
of the various hardware registers and indicators, while a 
Second table was used to store the basic microinstruction 
patterns. Other tables were used as aids in optimizing the 
generated code. Most of the optimizations involved the 
arrangement of elementary operations into efficient microin= 
Struction words (1.e.r words which take maximum advantage of 
parallelism). 

Another concept which deserves attention in the desian 
of a compiler for user-definable architectures is that of 
decision=logic tables {5,/44). Initially conceived to re- 


place flow charts in business programming applications, 
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decision tables have developed an extensive body of theory 
to enable tneir efficient use. A decision table consists of 
a group of alternatives for a given Situation and a set of 
actions to be taken for each alternative. In essence, this 
technique results in a tabular program rather than a table- 
driven program. 

In his discussion of registerstransfer languages,s, Bare 
bacci concluded with some very pertinent remarks. 


The proliferation of machines introduces a problem in the 
ONroduction of software. Standard languages (Portrams. 
Cobol, etc.) have alleviated the problen with respect to 
the user side but there still remains the variability on 
the machine side. Compoiler writing 1S an exnensive task 
and automatic orogramming systems (comoiler=compilers) 
have not taken into account this variability on the target 
machine. If we expect to solve the problem we need 
compiler~comoilers that accent aS inputs both the langquaae 
description (syntax and semantics) and the target machine 
description. None of the existing hardware desiqn 
languaqges 1s useful in this problem and the issue 1S not 
Meet the oroduction of coder but of "good" code .... 
(6, SO. 14) } 
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IX. CONCLUSIONS AND RECOMMENDATIONS 


As digital large scale integrated circuits and function=- 
al modules continue to have a greater itimoact on electronic 
system design, the need for improved software desiqn and 
application will become ever more critical in producing 
reliable, costreffective systems. Most of the concenovts dis- 
cussed in this thesis have been tn existence for a number of 
yearSr, but current hardware development trends cemand that 
Greater emphasis be placed on translating these concepts 
into realities. 

One of the key milestones in the effort to provide 
better tools for the design of systems using the new com- 
ponents will be the development of suitable high-level  opro- 
gramming lanquages for describing the algorithm. There are 
well over 100 high-level languages available todays each 
desianed to help solve a particular problem. "... (O)ne may 
question the need or desirability of all these languages. 
On the other hand, for the convenience of the users he 
snould be allowed to choose a language that he 18S comfort= 
able with and which best suits his application.” [48 p.3) 
The PL/M language, developed by Intel Corporations has been 
successfully used by firmware desiqners and may be able to 
be used as a base for newr, more comprehensive lanquages. 


Even if completely new Jlangquanes are developed, they will 


probably bear a strong resemblance to PL/M. 
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Major effort will have to be directed toward the 
development of compiler facilities which allow user specifi- 
cation of the hardware aspects of his design. This will 
require tne development of a good hardware description 
langquaaer which may or may not be a subset of the lanquage 
discussed above for describing the algorithm. In any event, 
the compiler will have the capability of manipulating this 
hardware information in such a way as to facilitate the gen- 
eration of control code. 

In order for this compiler to he accepted by system 
designers, it will have to generate "good" control code, 
with the specification of goodness being provided by the 
user. Thus there 1S a need for the continued development of 
practical compiler optimization techniques. In all of the 
work to be doner the optimization problems will probably be 
the most difficult to solve and the most crucial for the 
Success of the overall task. 

The work discussed in’ Chapter IV has been sufficient to 
indicate the feasibility of developing a high=level lanquaae 
for user=definable architecturess however, there are many 
Questions left to be anSwered and several important steps 
which need to be taken. The development of a formal tech 
nique for describing the semantics of a programming language 
Should have a high priority in this regard. Despite all. of 
the thoretical work which has been done to improve the syn- 
tax analysis and parsing processes in compilers, very little 


has been done to formalize the semantic analysis and code 


131 





generation orocesses [50,60]. The code generation process 
for the PL/M conpiler 1S juSt another translation (from 
intermediate language to machine language) and might be able 
to be performed in a manner Maniac to the parsing of the 
source language and generation of intermediate l|anguaade 
code. The use of a pushdown automaton for this process 
should be investigated. 

Error recovery during source language parsing 1S another 
area which deserves additional attention. It is desirable 
to provide the programmer with as much information as possi-~ 
ble, and the method 28 Gye in Section IV.B.4 1s relative= 
ly simple. Attention in this area should also be oevoted 
toward more efficient storage of error messages 1n order to 
help minimize the size of the compiler. One technique for 
doing this would involve the design of messages which can be 
partitioned into a relatively small number of common 
Ohrases. Detailed messages could then be constructed from 
these phrases. | 

The next step in continuing the work described in 
Chapter IV should be the design and implementation of a 
second pass for the PL/M compiler. Several snecific recom= 
mendations can be made here for future work in this area. 
Firstr a routine will have to be written to transfer the 
symbol tabdle to a disk file. This filers along with the 
intermediate language file and the initial value filer, would 
then be used as input for the second pass. The key to suc- 


cessful develooment of a “machine=independent"™ second pass 


13e 


will be the availability of a suitable hardware description 
lanquage and comoiler. when they become availble, they 
should be tested by using them to write a description of the 
Intel 5008 or 68080 microprocessor. In order to produce the 
control coder routines will then have to be written to store 
the necessary information from this descfiption in tables 
and to manipulate these tables according to the information 
received from pass 1. Until a suitable hardware description 
language 1S availablers, a more conventional pass e@ could be 
written, in the C languages for the PL/M compiler. This 
would provide a elsucine for testing various optimization 
techniques. Finallys optimization inputs must be defined, 


and the methods for utilizing them must be developed. 
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PL/wm 


ADR 
LIN 
LIT 
OPR 
VAL 


ADC... 
AUD Ds 
AND . 
ARG . 
ae 
ixa 
EXD. 
Bie: 
Cor rs 
CVA . 
DAT . 
oe 
Dil Sues 
DE 
DRE 4 
ENA , 
ENB. . 
END . 
ENP . 
CE 
GEQ . 
GTR. 
ny es 
HIlv . 
MENG. % 
INX . 
POI. 5 


APPENDIX A 


INTERMEDIATE LANGUAGE CODES 


Prefixes 


eee-e Load Address of Symbol 
eeee LINe Number Marker 
eeee Load Literal Value 
eeee Stack Operator 

joe OVMbOls Load Value 


LIBR Senos 
OR sae 
[OW tei oie 
Leer Baas 
MULES we 6 = 
Meo ee 5 BS 
NEQ ceece 


Procedure: Load Address 


Operators 


Add with Carry 

Add 

Logical And 

Procedure Argument 
Auxiliary tl 

Auxiliary e2 

Auxiliary 3 

BuilteIn Function 

Case Index Gperation 
Convert to Address (Double Byte) 
Data Start/Finish 

Delete 

Disable Interrupts 

Divide 

Default Return (End of Procedure) 
Enable Interrupts 

Enter block 

End of Do Grouo 

Enter Procedure 

Test for Equal 

Test for Greater Than or Equal 
Test for Greater Than 

Halt 

Extract High Order Byte 
Increment 

Subscript Index 

Logical Inclusive Or 

Test for Less Tnan or Equal 
Load 

Extract Low Order Byte 

Test for Less Than 

Multiply 

Negative 

Test for Not Equal 


134 


Sele 


TRC 
XCH 
XOR 


No Operation 

Logical Negate 
Origin 

Procedure Call 
Remainder 

Return 

Rotate Left 

Rotate Right 
Subtract with Carry 
Shift Left 

Shptt kivaht 

Store Destructive 
Store 

Subtract 
Unconaitional Transfer 
Conditional Transfer 
Exchange 

Logical Exclusive Or 
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APPENDIX B 
PROGRAM LISTINGS 


FILES m.eqram 
PL/M Syntax and Semantics 


aterm identifier number string 


yan | 
mt tis | 


#include 
Hinclude 


A} 
Ah 


program: 


, 
Statemen 


' Se 


i 
Statemen 


e 
basicsta 


/*x declarations used by actions and programs */ 


Ja Char kkk,tt? 


meee t - 
we GOO hue 


/*x beginning of grammar rules section */ 


Statementlist fx | x«/ 


tlist: statement /x 2 */ 
atementlist statement YRS 
t3 basicstatement /* 4 x/ 
2 {noush = Qf } 

ifstatement ee tae a 
= {npush = 0; } 


tement: aS S\gintmelntmrs) | Omak, 


= {while (S1l--) 


{if (fixvf{sp) > 0) emit (OPR,XCH); 


else {setsy(symloc{sol] ); 
emit CADR, getsyno());} 
pop (1); 
17 263) 230) emit COPR, SIC); 
else emit (OPR,STD); } } 
Grouon +5 | TSO Ee 
proceduredefinition 


returnstatement ‘';' 


callstatement ; 


Qotostatement '‘';'! 


declarationstatement';' 
iva lit. yor ee Vises kf, 


= femit(OPR,HAL); } 


enable' eae an ee 
= {emit (OPR,ENA); } 
disable’ ‘';' (£2 ae Go ed 


= {emit(OPR,DIS); } 
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i TR 16/57 
laveldefinition basicstatement /* 17 */ 
error ‘';° /* ERROR */ /* 18 */ 
= {errfix();} 


ifstatement: ifclause statement /x 19 x/ 
= {emit (DEF,spop()); } 

' ifclause truepart statement TR SCOMK7T 
= {emit (DEF,spop()); } 

' labeldefinition ifstatement x 23 k/ 

4 

ifclause: ‘if’ expression ‘then’ /* 22 x*/ 


= {emit (VAL,spusn(nsymtt) ); 
emit COPR,TKC); } 


truepart: basicstatement ‘else' LEC S Xf 
= {ii = spop(); 
emit(VAL,+spush(nsymtt+)); 
emit (OPR, TRA); 
emit (DEF,ii)d; } 


BiPOUP $ grouphead ending 4x 24 */ 
= {exitbIlk(); 
if ($2 >= 0) {flag("“identifier invalid here"); 
pop (1); } 
Switch(S1 & 03) 
{case 0: /x simole group */ 
~ emit (OPR-END); break; 
case 1: if ($1 & 04) /x stepdef w/BY */ 
{emit (VAL,spop()); 
emit (OPR, TRA); emit (DEF,spop());} 
else /x stepdef w/o BY */ 
{emit (VAL,11 = symfind(sp)); 
emit (OPR,INC); 
emit (CADR,iids emit COPR,STD); 
ii = soop(); emit (VAL,Spoo()); 
emit (OPR, TRA); emit (DEF,ii);)} 
pop (li); break; 


case 2: /* while group x/ 
11 = spoo(); emit(VAL,spop()); 
emit (COPR, TRA); emit (DEF,11)73 break; 
case 33 /x case group */ 
ij = spop()? spop(); jj = $1 >> 2; 
Kk = csp + (jj << 1); 


emit (DEF s,maketwolaekks*e(kkt1l))); 
emit (OPR,CSE); 
while (jje~) 
{kk == 2; 
emit (VAL,maketwolrkk,*«(kkt1))); 
emit COPR,AX2);} 
emit (DEF,11)7 
for (jj = (Si >> 2) + 1Lejjers) spop(); 
break; } }. 
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grouphead: Edo Se Vike 5 */ 
= f{enterbdilk(); emit (OPR,ENB), $3 = OF } 
' Vole steopCdetinition ° 7 /x 26 */ 
d{enterodik(); os = t+3e7 } 
‘'do' whileclause ‘';' i er al inal a 
= {enterolk(); $3 = e@; } 
‘do' caseselector ‘;' Sk (8 XH 
= f{enterndIlk(); 33 = 3; 
emit (VAL,spush(nsymtt)); emit (OPR,AX1I); 
emit (DEF,soush(nsymtt))7; soush(nsymtt); } 
qrouphead statement Je 29 xf 
= {if ((($h = $1) & 035) == 3) 
{emit (VAL,ii1 = spon()); emit (OPR, TRA); 
emit (DEF,spush(nsymtt)); 
spush(iids; 35 =+ 47) } 


steodefinition: variable replace expression iterationcontrol 
/x 30 */ 
= {$85 = 54; } 
; . 
iterationcontrol: to expression /* 31 */ 
= {$$ = 07 emit (OPR,LEQ); 
emit(VAL,spush(nsymtt+))*% emit (OPR, TRC); } 
' to expression by expression /* 32 */ 
= femit(VAL,ii1 = symfind(sp)); emit (OPR,ADD); 
emit (ADR,11)7 emit (COPR,STD), $3 = 4, 
emit(VAL,spop()); emit (OPR, TRA); 
emit(DEF,spop())-; } 
whileclause: while expression {x 35 x/ 
= {emit (VAL,Spush(nsymtt))7 
emit(OPR,TRC); } 


caseselector: 'case' expression /x 34 *x/ 
; 
proceduredefinition: procedurehead statementlist ending 
{x 35 */ 
= {if ($3 < 0) flaaq(“identifier required"); 
else tsetcy (oii 1 sceoetsyno!); 
1f C11 Wee symtind(ss)) 
flaa("“incorrect identifier"); 
Gop tie) } 
exitblk(); emit (OPR,END),; 
emit (OPR,ORT); emit (DEF,spop()); } 


a 


procedurehead: procedurename '‘';' f/x 36 */ 
= {procode(3$ = $1); } 
' procedurename type '‘';' /x 37 x/ 


= {setsy($5 = $1)7 setprec($2)% procode($i)7 } 
' procedurename parametertlist's' /* 38 */ 
= {setsy(55 = $1); setlen(¥2); procode(31)s } 
procedurename parameterlist tyne ‘';' /*x 39 */ 
= {setsy($5 = $1)37 setlen($e); 
Setprec(33)3 procode(31)7 } 
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: procedurename ‘interrupt’ number ';'! LAU x7 
= {procode($s = $1); } 


g 
procedurename: identifier ‘'s' "procedure' {x Yj x/ 
= {if (symloc($1)] >= curlev) 
flaq("illegal procedure name"); 
fixvl31l) = Of $3 = sytoo,; 
enter(fl,prot,0,0)% compress($3,1); 
pop (1); emit (OPR,ENP),; 
enterbIlk();} 


g 


parameterlist: oarameterhead identifier ‘')' /*x 42 x/ 
= {if Cacnt >= 63) 
{flag("too many parameters"); acnt = 62;)} 
setsy(t1); 
fixv(Se) = 07 $5 = +tacnt + (getlast() << 6); 
enter(se,undefr0r,1)7% compress(Sl-vacnt); 
pop (1);)} 
if 
parameterhead: a : /x U3 xk/ 
= {$$ = sytoo; acnt = 07 } 
' parameterhead identitier ‘,' /x QQ x/ 


= {$h = Bls acntt+ts fixvlse) = QO; 
enter($2,undefr0,1);7 


pop(1);} 
’ 
ending: "end! /* U5 */ 
= {$5 = -]1;7 } 
' "'end' identifier /* 46 *k/ 


= {$3 = $2; } 
: labeldefinition ending /* 47 *x/ 
S {33 = $e; } 


labeldefinitions: identifier ‘'s' {x QB x/ 
= {labflagtt, 
if (€€i11 = symloc($1)) >= curlev) 


{setsy(ii); 
if (getlen()) 
{i} = getsize() + finfo + 1, 
(symbol + ii) =& 03; 
emit (DEF, getsyno()); 
} 
else flag("*label redeclared"); 
) 
else 
ty xy bb) ) @=.0; 
bS = sytopn;s 
enter($i,labt,0,0)% compress(5$5,1); 
emit (DEFs,nsyme1); 
) } 
: number ‘3! 7% EOD K/ 
= {emit(L1T,-51)% emit (OPR,ORG)s } 


s ° 
returnstatement: ‘return’ /x 50 x/ 
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Vemit Cli ,0)7 emit (OPR-RET)> 3 
| ‘return’ expression Bees rf 
= VemileC@ni, heli. 7 


v 
callstatement: reali” Warivab We. 7* bse *7 
cs {setsy(symloc($2e]); emit (VAL,getsyno(l()); 
if (Cii = gettype()) == prot) emit (OPR,PRO); 
else {if (ii == cprot) emit (OPR,BIF); 
else flag("variable not a procedure name"); } 
poo (1), } 


v 
gotostatement: goto identifier 4x 53 */ 
= {emit (VALssymfind($2e)); emit (OPR,»,TRA); popll)?; } 
H goto number /x*x 54 x/ 
= {emit (LIT,$2); emit (OPR, TRA): } 
g 
Goto: NGO. ct) CO" TRO So kT 
raoto- x 56 */ 


i 
declarationstatenent: ‘declare’ declarationelement /* S7 x/ 
: declarationstatement ‘,' declarationelement /* 58 x/ 
e 
declarationelement: typedeclaration Jx 59 xk/ 
= {setsyl(curlev = *curlev), 
if (€gettype() == prot) 
{ii = getlen(); 
while (€ii-=~) 
{setsy(symbol + finfo +t getsize() + 2); 
if (gettype() == vart && getorec() == 0) 
Setprec(31i), 


} 
} } 
‘ identifier ‘'literally' string /*x 60 */ 


= { 

/x enter a macro definition x*/ 

Symbol = sytop-s 

setname(S1); /x fills sizernamerhcoll */ 
fixhcoll(), 

settype(mact); 

/x set the macro definition size */ 


setsym( (ii = getsize() + finfo), 
Setvaretij = Vor ts 5); 
setchar(t+ttitre jj); /x fills the macro definition */ 
/x note that last field filled is at end of entry */ 
syfin(); 
popl(e); } 
' identifier datalist TRG  k/ 


= {if (symcheck($1)) 
Cm elio= GO; 4) = Sytop; jj = ($e > 63); 
enter($1, jj ? Ilvect : svects1+s3$e)7} 
Tic. ie ecompress €11, 1); 
else {setsy(iiJds fixhcoll();} 
popll)s emit COPR-DAT)+- emit (DEF,spopl()); } 


Fr 
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datalist: datahead constant ‘')' /x 62 */ 
= Wd serie + concoGelte,datcon); } 
datahead: "dat aC /x 63 x/ 
= {Fh = Vs emit (VAL, spush(nsymtt+) )7 
emit COPR,TRA)s, emit (OPR,DAT); 
emit (DEF,nsym); } 
; datahead constant ',' x 64 x/ 
= {$5 = $1 + concodel3se,datcon); } 
a 
typnedeclaration: identifierspecification type Tx 6D KZ 
= {$5 = $27 11 = $1; 
if ($2 $= 1) change(vart,ter,ils,acnt); 
compress($l,acnt);} 
: boundhead number ')' type /* 66 */ 
= 17 ClSd et iaat" 1tlleqsal cGeclaration”™ ); 
$$ = $4, 11 = $17 
if ($2 > 63) change(Ilvect,34,52racnt); 
else {changel(svect,34,$e,acnt)? 
compress($l,acnt);}} 
é typedeclaration initiallist /* 67 k/ 
= {$5 = 317} 


tyoe: ‘byte’ /* 68 x/ 
= {Sh 22> ct = 3h; } 

' "address! /x 69 x/ 
= (Sea hte = ce} 


"label! /x 710 */ 
= {$5 = tt = 07} 


boundhead: identifiersoecification '(' /x Ti x/ 
= {$5 = $i;} 


a 


identifierspecification: variablename /x Te */ 
= fo =) bl, “Tt CJ ji) aeemt = 1, else acnt = 0; } 
‘ identifierlist variablename ‘')' 4x 73 x/ 


= {i f Cacnttt) $5 = $1; else $35 = $2;7} 


s 


moentifierlist: es /x TQ k/ 
= (acmt = 07} 
‘ identifierlist variablename ',' Ge [5 */ 


= {if Cacnt++) $8 = 317 else 335 = $27) 
av 
Variablenames: identifier /x 76 */ 
= {if (symcheck(51)) 
{fixv($l) = 0; 
$3 = sytop, 
enter ($Si,vart,1i,1i);} 
pon (1);} 
' basedvariable identifier LETT k/ 
= {if (fixvlbe) $= foundv) 
flaq("base not aefined"); 
else {11 = getsyno(); 
Setsy(31); setosynoliids } 
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$5 = $1; 
pon(1)7)} 


basedvariables: identifier ‘oased' /x 723 */ 
= {if (symcheck(b1)) 
{fixvf{d1l}) = basev; 
$$ = sytop, 
enter (Sl,vart,1,1)7} 


pop(1);} 
’ 
faitiallist: iInitialhead constant ')' /x 79 */ 
= {$$ = $1 + concodel($e,tt); 
if (tt) 


{putw(Sh,8buf3)7 setsyliid; 
putwlgetsyno(),&bufs)7} } 


| 
initialhead: minitral’ *(* /x 80 */ 
= Cfomea 0, tt ee. tt) 
flag("initial not allowed here")¢ } | 
‘ initialnead constant ‘'¢' /* 81 */ 
= {$5 = $1 + concodel($e,tt); } 


4 

assignment: variable replace expression 4x Be x/ 
= eases eS Ea) 

‘ leftpart assignment /x 83 x/ 
= sie = tt be, oy 


, 


replace: rs! /* B84 */ 
, 
leftpart: variable '‘',' Tk Book 
’ 
expression: logicalexpression /x 86 x/ 
' variable ‘':' ‘= logicalexpression /x B87 x/ 
= {if (CfixvflSid) emit COPR,XCH); 
else emit (CADR,symfind($1)); 
emit(OPR,STO); poplids } 
’ 
logicalexpression: logicalfactor 4x 88 x/ 
‘ logicalexoression ‘'or' logicalfactor /*x 89 */ 
= {emit COPR,ITOR); } 
logicalexpression ‘xor' logicalfactor /* 90 */ 
= {emit C(UPR,XOR); } 
; 
logicalfactor: logicalsecondary /* 91 */ 


; loagicalfactor ‘and’ logicalsecondary /x Ge */ 


, 


logicalsecondary: logicalprimary 4x 93 */ 


‘ ‘not’ logicalprimary /x 94 x/ 


= {emit (COPR,NOT); } 


g 
loaqicalprimary: arithmeticexpression GR 9D */ 
‘ arithmeticexoression relation arithmeticexpression/* 96 */ 


= {emit (UPR, S2)7 } 
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A 
meat ion: ' 
= (33 >= 2Gl 
' at fx Far 7 

= {ib = Eso7es 
' eS JF KO OGD KT 
{$4 = GTR; } 


f/x 97 x/ 


swe 6 


' a ar a ieee OLA 
= {$$ = NEQ; } 

: Veale = /x 101 x7, 
= {$5 = LEQ; } 

'>' ts! /x 102 */ 


= {$5 = GEQ; } 


arithmeticexpression: term /k* 103 */ 

: arithmeticexpression ‘'+t+' term /*k 104 */ 
= {emit (OPR,ADD); } 

} arithmeticexpression ‘'*' term /* 105 */ 
{emit (OPR,SUB); } 

' arithmeticexpression ‘plus' term /* 106 x*/ 
= {emit (OPR,ADC); } . 

‘ arithmeticexoression ‘minus’ term /* 107 */ 
= {emit (OPR,SBC); } 

' "=' term /* 108 */ 
= {emit (OPR,NEG); } 


terins primary 4x 109 x/ 

' term '*' primary /x $10 x*/ 
= {emit (OPR,MUL); } 

term '/' primary /x 111 */ 


= {emit (OPR,DIV); } 
} term ‘mod' primary /* 112 x*/ 
= {emit (OPR,REM); } 


primary: constant LAA kT 
= {if (conlast == stringce) 
{11 = varfsp)] + 1; 


Switch (31) 
{case 1: emit(LIT-,getvarclii)d); break; 
default: 
flleqt strima, must be ft or 2 chars’); 
case 2: 
emit(LIiT,maketwol(getvarcliitl), 
getvarc(iid)); } 


pon (1); 
} 
else emit (LIT,S1); } 
' ." constant Je 1145 


= {emit (VAL,spush(nsymtt))7 emit (OPR, TRA); 
emit (OPR,DAT),s emit (DEF,0); 
concode (Ser pricon),; 


emit (OPR,DAT);, emit (DEF, spop()); } 
‘ Constontunemea comstamt “S° /x {15 */ 
= {concodels$e2,s,pricon); 


143 





emit (OPR,DAT); emit (DEF,spop()); } 
' variable /* 116 */ 
= {ii = symfind( 451); 
if Citi >= 0) 
{switchlaettype()) 
{case prot: emit(VALrii)s emit (OPR,-PRO); 
break; 
case cprot: emit(VAL,i1)% emit (OPR-BIF); 
break; 
default: if(!ifixv(S$1]) emit (VAL,i1);3 
else emit(OPR,LOD)7} } 
pop(1); } 
'.' variable Se 117 */ 
= {if Cifixvl$2)) emit CADR,symfind($e2)); 
emit (OPR,-CVA): popol(l); } 
we’ -expressivom ')' 7x 1186 */ 


Gomstanthead: ~.° ‘(° Je 119 */ 
= {emit (VAL,spush(nsymtt+))7 emit COPR,TRA); 
emit (OPR,-DAT); emit (DEF,0);7 } 


: constanthead constant ‘,' /* 120 */ 
= {concodelse,pricon); } 
, 
Variable: identifier Je Nie li he 
= {undec(); fixv(Sh = $1) = OF } 
' subscriothead expression '‘)' /* jee */ 


= {i1 = symfind( $1); ++fixvl35 = 31]; 
if (Cjj = gettype()) $= prot && jj $= cprot) 
emit (OPR,INX); 
else emit (OPR,ARG); } 
c 
subscripthead: Veoentiutver «7 fx 125 */ 
= {undec(); fixvfiSS = $1) = 07 ii = symfind($1); 
Wome yi me roettypeG)) | != orot && 3). != eproet) 
emit (ADR,it)?7 } 


} subscripthead expression ‘-' S/* 124 *&/ 
= {ii = symfind(31); 
if (Cjj = gettype()) == prot t+: jj == cprot) 


emit (OPK,ARG); } 


e 
a 


constant: Strima, 7* 12s *7 
= {$5 = getvarc(var(sl])- } 
‘ number /* 126 x/ 


= {3d = S11; } 


woe 6‘ tol" (eed ks 
= {emit CADR,ii = symfindl(sp)); 
emit (OPR,STD)3 emit (DEF,soush(nsymtt) )7 
emit (VAL,i1)% } 
; 
by: ‘by' /* 128 */ 


= {emit (OPR,LEQ); ii = spon); 
emit (VAL,spush(nsymtt)); 
emit (OPR- TRC) emit (VAL,j) = nsymtt); 
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emit(OPR, TRA); emit (DEF,spush(nsymtt) ); 
spush(€jj)d; snushlii)ds } 


td 
while: ‘'while' Je 129 x/ 
= {emit (DEF,spush(nsymtt))7 } 


« 
a 


Mike /* beginning of programs section */ 


Hinclude "m.scan.c” 
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#define 
Rdefine 
“define 
#define 
#define 
Rdefine 
Hdefine 


Bdefine 
#define 
#define 
Ldefine 
RFdefine 
tdefine 
#define 
#define 
Hdefine 
#define 


Hdefine 
Hdefine 
#define 
Hdefine 


/* $1ze 
Hdefine 
#Hdefine 
#¥define 
define 
Rdefine 


/* maximum number of 


Hdefine 
Hdefine 


#define 
Kdefine 


/* symbol 


#Hdefine 
Rdefine 
Hdefine 
Adefine 
Kdefine 


/*x* symbdol 


Rdefine 
#define 
tdefine 
Fdefine 
Kodetine 


FREE?) mode t 
Macro Definitions 


true. 1 

false QO 

auote 39 

doeforever while(1) 
UNKNOWN 7128 

EOF =~] 

SIGN 0100000 


errc QO 
identc 1 
numoc e 
Steimoc 5 
specl 4 

eofc 5 

num& 6 
datcon 8 

oup (alee ies 
hashmask le? 


binv e 

Getv & 

decv 10 

hexv l6 

of symbol table 1s symsmax + 1 */ 
symsmax 4096 
maxsyno 1023 
maxlen 16383 
Varenmax ic/ 

stackmax 29 


4x syno field is 10 bits */ 
/x lenath field is 14 bits */ 
last location in varc */ 
/*x* ton of voarsing stacks */ 
levels of macro nesting */ 


/* 


macmax 19 


maxblk 19 /*k maximum block nesting level */ 
foundv e 


basev 1 


table fields */ 
lastf 0 
typef 1 
Sizer ¢ 
namef 4 
finfo 3 LT ixeGuintowin.  symools */ 
table 
rest 15 
undef Q \ 
mact 1] 

Vomit c 


arrt $3 


types */ 


146 





Rdefine strt 4 
Hidie fine labt 5 
Hdefine prot 6 
#Hdefine cvart 7 
Mgefine cprot §& 
RFdefine ivart 9 
#define outpt 10 
#define lvect 11 
#define svect lie 
#define clabot 13 


Me Uperators for “emit” x*/ 
H#define DEF 
#define ADR 
Hdefine VAL 
Rdefine OPR 
H#define LIN 
#define LIT 


CHEW N eS S&S 


/* Polish Onerators for “emit" */ 
Hdefine NOP ] 
define ADD 
#Hdefine Subs 5 
Adefine ADC 4 
Adefine SSC 5 
H#define MUL 6 
#define DIV 7 
RFdefine REM 8 
#Hdefine NEG 9 


#define AND 10 
H¥dJefine IUGR 11 
#define XOr le 
tdefine NOT Ts 
tdefine ctQL 14 
Rdefine LSS rS 
tdefine GTR 16 
Rdefine NEU 1/7 
FAdefine LEQ 18 
Adefine GEG 19 
Adefine INX cv 
“define TRA el 
#define TRC ec 
#define PRO es 
Bdefine RET ed 
tdefine STO 25 
Hdefine STD 26 
#Jefine ACH el 
define DEL 28 
Bdefine DAT e9 
#define LCD 350 
Hdefine BIF 51 
Haefine INC $e 
Hdefine CSE So 
#define END. 34 
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#Hdefine 
Sdefine 
Rodefine 
tdefine 
Bdefine 
Fdefine 
Adefine 
#aefine 
Hoefine 
fdefine 
a#define 
H#define 
define 
Rdefine 
tHdefine 
#define 
#Fdefine 
edefine 


ENB 
EivP 
HAL 
RIL 
RTR 
Siete 
SFR 
HIV 
LOV 
CVA 
UKG 
DRI 
EWA 
DIS 
AX] 
Axe 
Ax 
ARG 
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FILE? aam.cdec | 
Global Variable Declarations 


Mat liejtr, char *kkptt? 


Nt NSYmMe 4x next symbol number */ 

4* npush 18 no. of Ssymools pushed for current statement */ 
Char npush; 

/*x lanflaq indicates if current statement has a label */ 
char labflag; 


mNt acnt; 

char conlast? 

Int yylines /* line count */ 

Nt yydebugs /x debug switch */ 


/x* comoiler toggles */ 


char toad, /x deoug */ 
togp, /x oroduction listing */ 
togt,s /* token listing */ 
/* line limits for toggles */ 
int liml, 4x lower limit */ 
limu, /zx uoper limit */ 


char tokens Styper, hashcoder Jlastcr nextc; 
‘Int value; 

char errset, 

char xhentrylhashmask + 1); 


/x  ‘symbol' is the base address of the currently referenced 
Symbol table entry. '‘'sytop' is tne current too of the 
Synbol table. ‘tokrel’ is used to hold ‘symbol' for 
certain tokens during syntax analysisr and eventually 
makes it to the 'symloc' stack corresponding to the ele- 
ment (if zeror the token was either not looked up or not 


found).  / 
char symoolslsymsmax + 1); /x symbol table */ 
char *symbol,xsytop,*tokrel, 
Char maxsyr J/x* minled4s &symoolslsymsmax)]) = Symbol */ 
sylast; /x last location filled during 


symbol table construction */ 
int syrel,s /x relative address of current symbol */ 
syres; 4x first symvdol!l location after reserved words */ 


/* token accumulation */ 


char varclvarcmaxtl]); /* temporary character storage */ 
Nt varindex, /* next free varc location */ 
tokindex, /x start of accumulator in varc */ 
acclen; 4x lenath of accumulated token *t/ 


/* parsing stacks */ 
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char hashl(stacxmaxtl]); /* hash code for entry */ 

int fixv(stackmaxtl], /* temporary use during parse */ 
var(stackmaxtl]; /*x start location in vare for entry */ 

char *symloc(stackmaxtl),; /* symbol table location */ 

char sp; /x stack pointer */ 

Char *csp, /* symbol number stack pointer */ 


/k mactop is the current top of the macro expansion stack, 
andr when mactop is greater than zeros *macaddr(mactoo] 
points to the current symbol string being expanded in the 
symbol table. the maclen table gives the number of 
characters remaining to expand at this level. x / 


char mactoo, *macaddri(macmax + 1); 
char maclenlmacmax + 1); 
char macnext (macmax + 1)7 /* holds ‘'nextc' for each level */ 


4x block keeps track of the current Sympdol table top for 
each block level. the variable blklev points to the 
current pnlocKx level in block. the value of curlev is 
blocklblklev]. blilkv is a stack used for saving the 
value of noush at each level. x / 

char *block[(maxbIlkti],*curlev,; 

char blkv(maxblktl); 

char blklev; 


/* ouf is a structure used for buffering 10 */ 
Struct buf { 

int fildes; //file designator 

int numuSsed; 

char *nxtfree; //ouffer pointer 

char buff{5l2);3 //512 byte buffer 


} ; 
mermucet but bufl,; L/7SOt ter Oc. - Pim. Wee 
Struct buf bodufe; //oufter for ogetc 
Sunuiet buf buf 5; //ouffer for “plmei.v"™ 
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PILES m.oact.c 
Procedures Invoked by Semantic Actions 


Hinclude "“m.def" 
#include "m.decl|”" 


symcheck (1) 
char is 4 
rt CsSynlocliyile= curlev) 
{setsy(symliocliJ),; 
if (gettype() != undef) 
iflag("variable redeclared"); 


return (jj = true);} 
acnt--3 settype(vart); return (jj = false), 
} 
return(jj = true); } 


symfind(1) 
G@nar ir ( 
if (i < 0) return(-l); 
if (synlocli] = symbols) 
{setsy(symlocli]) ); 
Switch(qgettype()) 
(easemvanmu: case "cvact ; 
case prot: case corot: 
case lIvect: cease svect: 
case ivart: case outpt: return(getsyno()); 
break, 
default: 
flag("identifier cannot be a variable"); 
return(-l)- } } 
else 
{flag("undeclared variable"); returnl-1)7} } 


emit(Cal,sac) 

char als int ae; { 

if (Cerrset) return; 

Switch(al) { 
case LIN: a2 = (a2 & O17777) ¢ 0400007 break; 
case LIT: putclal << 4,&bufl); break, 
deftawmlecrace= (ae & OOFTT7T) + Cal << 12); } 

putcChigh(acd),&bufl); 

putcl(lowlacd),s&bufl); } 


/* note that the soush and spop routines operate on 
Pestack', which is actually an area at the top 
of the symbol table. x / 


snush(sn) 
/* push a symbol number onto cstack */ 
Int snz | : 
if (csp <= sytop + 1) 
{tflag("cstack overflow");} 
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aoe 65 2) — shai (sims 
aC--csp) = lowlsn); 
return(sn); } 


spop () { 

/x pop a symbol number from cstack */ 

char 13 

if (csp >= &synbolslsymsmax] ) 
{flag("cstack underflow"); 
return(-1)7 } 

= A (CG ptt); 

return(maketwolir*(csptt))); } 


precode(sy) 
/*x* emit code for a <PROCEDURE HEAD> */ 
jimt Sy, 4 
emit (VAL,spush(nsymtt));7 
emit (OPR, TRA): 
setsy(syJ); 
emit (DEFs,getsyno()); } 


concode(v,t) 
Jk emit code for constants */ 
doe V; Char t, { 
char +0 je 


mi Cconliast == strinac) 
{for (41 = 17 +4 <= vz itt) 
{j = getvarc(i + varlsp)); 


+f (t < datconm) putcl(j,*buts)? 
else emit (LIT, j); 
} 
pop(1); returnlv);3 
} 
/k* constant 1S a number */ 
if (t >= datcon) 
femit(Lll-v)? return((v > 255 tt: v < 0) + 1)7 } 
Jk initial constant */ 
Switch (t) { 
case 0: return(0); 
case 1: putclv,&ouf3); 
if (conlast $= numd3) 
flag("single byte constant required"); 
return(1); 
case 2: putwlv,&duf3); 
peuurn (come ~~ } } 
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Pili Simao x = C 
Auxiliary Procedures 


amc luge "m.def” 
Rincluge "n.oaecl" 


char high(n) /*x return high byte of an integer */ 
int Mn, { 
return (n >> 8); } 


char low(n) /x return low byte of an integer */ 
Int nz { 
return. (n)? } 


int maketwo(i,j) 
/x return 16 bit value constructed from i and j */ 
char i¢je { 
return ((j << 8) {| Ci & 0377))7 } 


int norm) 
char 13 { 
/*x ensures that cnars with msb = 1 
are converted to integers in the 
range (128,255) rather than to 
negative integers x/ 
fo UuNGchim Clee s0me coo fois 1) 7 } 


oush(1) 
/*x stack the last token in varc */ 
char if { 
npushtt; 
if (++sp > stackmax) 
{flaa("stack overflow"); so = 0% npush = 07} 
var(sp) = tokindex, 
varcl(tokindex) = acclen; 
tokindex =t acclen + 13 
/* varc is ready for another token */ 
fixvf(sp) = i; 
hash{so) = hashcode,s 
symloc{(sp) = tokrel; } : 


pop (n) 
/* remove n tokens from the stacks */ 
char ngs | 
if €laoflag) {n =+ labflags labflag = 0 
for (3 n > 07 n-r) 
{nopushe-r; 
it tsp < 0) 
{flaq("stack underflow"); 
sp = -17 noush = QO, return;} 
tokindex =- varclvaritsp--7)) + 1; 
» } 


ba 
aye 


Ge 





Poliee es ms en nse 
Error Routines 


Panic iuae “medet 
Hinclude "medec)” 


flaglerr) 
char kerr; { 
printf("\ncomnpile error, line 4d $3 48\n"szyylineserr)s 


tflaglerr) 
Char *err; 
{flaglerr),; 
exit()7} 


errfix() { 
/k procedure for error recovery following 
oiscovery of a syntax error on input x/ 
errset = trues 
pop (npush)? } 


undec () { 

4x check for undeclared variables */ 

if (fixvftso) != foundv) 
{flaq("variable undeclared"), 
enter (sp,undefr0,1); 
setsy(sytop =~ *sytop); 
synmloc({sp)] = symbol; 
fixncoll|l(); 
} } 
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} 


Pole. m.scan.c 
Lexical Analysis Routines 


4x lexical analysis */ 


char getvarc(i) 
char i7 
{return Cvaretnonmt(s) 377} 


ear gnc () 
{ /* get next inout char */ 
char ig int jz 
while (true) 
{if (€Cisgetc(&oufe)) != '\r') && 
(7 $= "Nn')) 
returnlid; 


else 
{if (togd) 
{if Cyyline == liml) yydebug = true; 
if (yyline == limu + 1) yydebdug = false; 
} 
emit (LIN,ttyyline); 
} 
= 
Char readino() { 
char CC; 
1f (mactop > 0) /x then expanding a macro */ 
{if (i Ce-maclen(mactop]) )) /* maclen == 0 x*/ 


/zk then end of macro expansion: restore nextc */ 
return (macnext (--mactop) ); 

/* otherwise continue expansion */ 

returm Cr Ct+tmacagdarimactonol) )); 

} 


/* otherwise read from input device */ 
meturn Cane); 
} 


Zeroacc() 
{ /x zero accum parameters k/ 
Stype = hashcoge = acclen = value = Q; } 


saver() 


{ /k save characters in the accumulators, and compute 
the hashcode */ 


an Geen I 
hashcode = (hashcode + nextc) & haShmask; 
if (€(3 = ttacclen + tokindex) >= varcmax) 
{flagt’ vo); 
acclen = 07 )} . 
else varcli] = nextc; } 
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char numeric() 
{ /x return true if nextc is numeric *k/ 
return (norm(nextc7'0O!') <= 9); } 


char hex() 
{ /x return true if nextc is hexadecimal */ 
return(numeric() +i (norm(nextc='a') <= 5)); } 


char letter() 
{ /x return true if nextc is a letter */ 
return (norm(nextcw'a') <= 25); } 


Char alphanum() 
{ /x return true if nextc is alphanumeric */ 


return (numeric() tt letter) )7 } 


gettoken() {/* get tokens for the parser x/ 
Char brdrirenege 
Tat V;, 


Zeroacc(); 


{ 7x fimnageinirteral choracter */ 
{token = 0; 
while (token == Q) 
{ /* deblank input */ 


while ((nextc==unknown) v4 (mextG=="°  %) 
~eerGnextc== Nt 
nextc = readinp(); 


/x check symbol class */ 


if (letter()) token = identcs else 
if (numeric()) toKxen = numbc;s; else 
1f (nextc == quote) 
{token = strinacz nextc = unknown;} else 
/x this must be a soecial char */ 
{lastc=nextcs saver(); nextc = unknowns 


Vel (las tc== 7") 
{ /xk may be a comment */ 


if (€nextc=readinp())=='%') 
{while (!(€€(€nextc=readino())J=='/') 
&& Clastc == ‘'x'))) laste = nextc; 
nextc=unknown; zeroacc();} 

else /*x just a / */ token = specli;} 


else 
if (€lastc==EUF) token=eofc; 
else token=specl; 
if (token != 0) return;}} 
/x end of checks .for symbol class */} 
/x end of check for token = 0 */ } 
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/* symbol tyove discovered, scan remainder *k/ 
while (true) 

{if (nextc != unknown) saver(); 

lastc=nextc; nextc = readinp(); 


We Ctocen ==) 1centc) 
{if (nextc == 'S$') nextc = unknowns else 
if (!alphanum()) return; } 


else 
wt (token == numboc) 
{if (nexte == '$') nextce = unknowns else 
if (!nex()) /* end of number found */ 
(at Me@cnemte== OC leer mextc=='q')) stype=octv? 
else | 
if (nextc=='h') styne = hexv; 


if (stype > 0) nextc = unknown; 
else 
tanec baste== "6" ) 

{--acclens styne=binv;} 
else 
if (€lastc=='d') 

{e-acclen; stype=decv;} 
else stype=decv, 


/k now convert number to binary */ 
value = 0; neg = false; 
for (i=1; i<=acclens itt) 
{if ((d=getvarcli + tokindex)) >= ‘'a') 
d=d-'a't10; else d=d-'0'; 
if((b=stype) <= d) token = errc; 
v = values value = d; 
while (b =>> 1) 
{if (v & SIGN) token = errc; 
Veale a <a [= 
jitemGioe & |) 
{if ((value + v) & SIGN) 
neq = true; 
Value =+t vs 
if (neq && !(value & SIGN)) 


token = errc? 


} 
} 
} 
/* binary equivalent is in ‘value’ */ 
return;}} 


else 
if (token==strinac) 
{if (nextc==quote) 
{if ((nextc=readino())!=quote) returnzs}} 


TS? 





} 


prntok() { 
/* print token info */ 
int 1, 
Butchar (9Ne ), 
for (1 = 1; 4 <= acclen; itt) 


putchar(varc (tokindexti] ); 
Prime t(" \mt=2.0s=“20 l—-e v=-4 le h-40", 

toxen,styoe,acclenrsrvaluerhashcode); 
putchar('\n'); ~~ } 


vylex() { 
/*x lexical analyzer == interface between 
yyparse and gettoken & / 
char i 
tokrel = symbols, 


doe forever { 

gettoken(); 

if (toqt && yyline >= liml && yyline <= limu) 
pratok(); 

Switch (token) {4 

case eofc: 
return ('\0O'); 

case speci: 
return (Clastc); 

case stringc: 


push(0); 
conlast = stringc; 
yylval = s09,; 


return (string); 
case numoc: 
conlast = (Chiqh(value)) ? numbc : num8; 
yylval = value, 
return (number); 
case identc: 
lookup); 
tokrel = symbol; 
Ft oct ound ()) 
Switch (qettype()) { 
case rests 
return (getresno() + 256); 
case mact: 
/x start macro expansion */ 
4x save lookahead cnaracter for 
restoration following the 
Macro expansion x / 
macnext(mactop) = nextc; 
nextc = unknowns 
if (++mactop > macmax) 
{mactop = 0; flagq("md");} 
/* set up definition */ 
maclenlmactop) = getmsize() + 1; 
macaddritmactop) = getmdef(); 
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breaks 
det aunlkw: 
pusn(foundv)s 
yylval = so; 
returnCidentifier)s } /* end of ifl€found()) */ 
else if (Cacclen == 3 
&& getvarcltokindextl) 
&& getvarcltokindexte) 
&& getvarcltokindext3) 
return C'\O')¢s /* eof */ 
else { /k unknown identifier */ 
push(0); 
yylval = sp, 
return Cidentifier)s } 
Jk end of unknown */ 
break; /x end of case identc */ 
case errc: 
flag("number conversion error"); 
yylval = value; 
return (number), 
} /* end of switch(token) */ 
} /* end of doeforever x*/ 
} /x end of yylex() */ 


ec 
O 
f 


) 
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rome ¢ mesymec 
Symbol Table Routines 


“aumcilude "“m.det 
“include “m.dec!” 


setsy(a) 
char *a; { 
int dV, 
/* set symbol to point to symbolsla = symbols) */ 
symbol = a, 
syrel = symbol = symbols; 
/x set maxsy so no overflow can occur 
when filling the symbol table x/ 
if Chighli = csp = 1 = symbol) == 0) 
maxsy low(i) & 0376; else 


maxsy = 254, 
/* note that maxsy <= 254 */ } 


/x the getxxx procedures which follow assume 
that Symbol 1s set to the base of the 
currently referenced symbol table entry */ 


char qetsym(i) 
char 17 { 
return (symbol (norm(i)));  } 


char getlast() {4 
/x aet the value of the ‘last’ field */ 
return (getsym(lastf))s; } 


char gettype() { 
/* get the value of the ‘type’ field */ 
return (getsym(typef) & 017); } 


Char getsize() { 
/xk aet the value of the ‘size’ field */ 
Fo cuinne (geiwsym( size) ), } 


char getname(i) 


char i; | { 
Lr Gdewmmenagacter 1 of the “name” field */ 
return (getsym(norm(i) + finfo)); } 


int gethcoll() { 
/x get the hash collision field */ 
char , 
i = getsize() + finfo = 23 
return (maketwol(aetsym(l(i), 
getsym(1 + 1)))7} 


Char getresno() { 
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/x get the reserved word number */ 
return (getsymlgetsize() + finfod)s } 


char getmsize() { 
/x get macro size */ 
Peouunneagetoym(getsyzZe( Jet Sfinto), )} 


char xgetmdef() { 
/x get the absolute address of 
macro definition pase =] */ 
return (norm(getsize()) + finfo + symbol); } 


int getsyno() { 
/* get the symbol number */ 
/* assumes 10 bit field */ 
char 13 
1 = getsize() + finfo; 
return (maketwolgetsymli), getsym(itl) & O3))7 } 


char getprec() { 
return (Clgetsym(typef) & 0160) >> 4); } 


cnar getcased() { 
/*x* aet the based variable field */ 
return (getsym(typef) < 0)7 } 


int getbsyno() { 
/x get the bsyno field */ 
/*x* assumes a 10 bit field */ 


char 3 

1 = getsize() + finfo + 23 

return (maketwolgetsymli),getsyml(iti) & 03)); } 
int getlen() { 


/* qet tne lenath field */ 

/k assumes a 6 bit (snort) or 14 bit Clong) field */ 

Ener ir INt |e 

i = getsize() + finfo +t (getbased() ? 3 : 1)7 

1 = norm(getsym(1)) >> 2; 

return ((gettyoe() == Ivect) 
(norm(getsymliti)) << 6) 


= = ea) 


/*x tne setxxx orocedures which foilow assume 
that symbol 1s set to the base of the 
currently referenced symbol tavle entry */ 


setsym(i,x) 
char 14? { 
if (norm(sylast 
symbol (norm (i)) 


i) > norm(maxsy)) tflagl"to"); 
Melos o 


settype(t) 
char te { 
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setsym(typef,(getsym(typef) & 0560) §: tds } 
Ssetsize(s) 

elvele Es { 

setsym(sizefss); } 


sethcol|l (hc) 


imate DC; { 
char i; 
setsym((i = getsize() + finfo ~-= 2), low(hc)); 


setsym(i +t lehighlhco))37 } 


setresno(})) 
/x set reserved word number */ 
@ hanes 
{setsym(finfo + getsize(),i)z7} 


setsyno() { 
/x set the symbol number field */ 
/* assumes 10 bit field */ 


cnar 1, 
if (nsym > maxsyno) tflaa("too many symoo)s"); 
setsym((i = getsize() + finfo)s, lowlnsym)); 


setsym(i + le high(nsymtt+) |; Cgetsymlitl) & 0374)); 
return(nsyn - 1)¢ } 


setprec(p) 
/* set the precision field */ 
char p; { 
Seucymucype wmugetsym(typet) © O2t7 J, Co << 4))7 } 


setbased(b) 
/x set the based variable field */ 
Chan ub; { 
setsyn(typefs(getsym(typef) & 0177) | (b ? 0200 : 0))7 } 


setosyno(i) 
/* set the wsyno field of a based variable 
entry to the symbol number of the base *t/ 
/x assumes a 10 bit field */ 
Int We { 
char je 
setsym((j = getsize() + finfo + 2), lowli)); 
setsym(j + 1, high(i)d ¢ Cgetsym(jt+1) & 0374))5 } 


setlen(]) 
/*x set the length field */ 
/xk assumes a 14 bit Clong) field */ 
int J; { 
char 4 
1f (1 > maxlen) flag("vector lenath too large"); 
/x wased field must have been set already x*/ 
1 = getsize() +t finfo +t (Cgetbased() ? 3 : 1); 
setsyn(is Clow(l) << 2) «¢ Cgetsym(i) & 03)); 


162 





Setsym(iti, } >> 6); } 


int found() { 
/x returns true if symbol does not address 
the base of the 'symbols' vector x*/ 
return (syrel)z } 


lookup () { 
/* look for accumulator match 1n symbols 
based upon current value of hashcode */ 
Char ie *je 


/* ‘symbol! is set to the top=most symbol 
with this hash code x / 
setsy((j = hentrylhashcode]) ? j : symbols); 


/x the value of the ‘found' procedure is false 
if the symbol name cannot be found in the table */ 
while (€found()) 


{/* ‘symbol’ points to possible match in table */ 
if Coetsize() == accien + 2) /* then length match */ 
for (1 = 07 aetname(i) == getvarclitittokindex);) 


if (++i == acclen) return; 
/* no match, so look again */ 
setsy(gethcoll() + symbols); 
/x ‘synool' is now Set to the next symbol 
with this hash code « / 
} 


seremar ts], vl) 
/* ‘place characters from varc into symbol] table 
Startinomet vl im Vare and sl in symbol. the 
length of the transfer is obtained from varclvl). */ 
char sSlevvl, { 
char 7 
1 = getvarc(vl); 
while (1) 
{setsym(sl-,gqetvarc(ttvl)); 
Sit tele 


Pai 


setname(s) 
/*x* set size, namer and hcoll fields 
fron vew at s x / 
Char ss { 
char ke 
setsy(sytopo); 
setsize(getvarc(k = varlts)) + 2); 
setchar(nanef,k); 
/* temporarily store hashcode tn hcoll field */ 
sethcoll(nash(s}); } ' 
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farxcnco! iC) { 

/*x fix the hash chains using the hashcode 
value stored tin the hcecoll fiela «x / 

/* assumes symdol has been set */ 

char *p- int ve 

sethcoli((p = hentryli = gethcol!l())) > 0 ? 

(pop ~- symodols) : 0); 
hentry{li}) = symbol; } 


syfin() { 
fx finish construction of 3a symbol table entry, 
assuming the highest fiela in the entry was 
filled last (thus setting sylast). x / 


4x note that sylast <= 254 x«/ 

setsy(sytop =+ (ttsylast)); 

/* now addressing next symbol table entry */ 
setsym(lastf,sylast); } 


enterbd!lk() { 
4x enter a new olock level */ 
THectt+tDI)kleva> maxbd] k) 


{flaa("po"); blklev = 237} 
blikvlolklev} = npushs npush = 0; 
curlev = blocklblklev) = sytop,; } 

exitb)lk() { 


/* exit current block level */ 
char hrjrisr char AD; 
f/x remove innermost symbol) tadle entries */ 
if (e-blkiev < 1) biklev = 1, 
setsy(syton); p = sytop,; 
while (p > curlev) 
{o =- norm(getlast()); 
setsy(po); 
/e* entry removed, fix hash entrysr 1f necessary */ 
if (1 = getsize()) /* > 0 then recompute hashcode */ 


{h = 07 
for (j = 07 norm(e"i) > ly jtt ) 
h = (h + getname(j)) & hashmask; 
hentrylh) = gethcoll() + symbols; 
} } 


} 
/* remove any currently expandina macros x*/ 
while (€macadar(mactop) > p) && mactop > 0) 
~=— mac t OP's 
/* reset current level */ 
npush = blkvlbilklevl; 
curlev = blocklolklevl]; } 


emcer(ptry tr ov 1) 
f/x maKxe an entry in the symbol table */ 
enar OUFrtlsp-r Int lz { 
setsy(sytop), 
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settype(t); 

severee(p) ; 

1f (otr os UV) 
{setbased(fixviptr]): 
Setname(ptr); } 

else /x Symbol has no Orintname x/ 
{setbased((); 
Setsize(U); ) 

BeteSyme(); 

i f (fixvfptr) =: basev) Setdsyno(0); 

Setlen(1); 

Sry fii) > } 


Change(t, p, |, n) 
/*& change Che type, Precision, and length fields 


Of the last n Symbol table entries x / 
Char trp; 
int lin; { 


setsy(sytop); 

for (3 n > QO; n=~) 
{setsy(symbo] - norm(getlast())); 
Settype(t); 
ie Ct == lvect) fixhcoll(); 
Setprec(p); 
Setlen(1); 
} 


Setsy(sytop); } 


Compress(ptr,n) 
/* remove Che second byte of the length fielg 
from n symbo} table entries Starting at ptr «/ 
Char kote; {nt nN; { 
mat i, ji-k> Char kp; 
if (In) return} 
Setsy(ptr); 
/* fix hash Chains for first CNthya x / 
tTixhcoll(); | 
DOtr =+ finfo + norm(getsize()) + (getbased() ? as eo; 
Mee (i = ji; = < Ne itt) 
{setsy(ptrtj); 
kK = finfo + Norm(getsize()) + (getbased() ? 3 
~“=Symbol (0); 
POne(; = @> j <= ke jtt) 


oe 
pe 
Vw 
™e 


Seti} = Symbol (jJ; 
/* entry is NOW IN its final POSIition, 
SO f1x hashcode Chains x / 


Setsy(ptr); 

fixhcoll(); 

OU etik et | - 

} 
Pte lO] = ptr{n) - 1; 
SYtOM = ptr; 
setsy(sytop); } 
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